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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



In order to support packet based services with low latency requirements belonging for example to the Conversational 
QoS class in GERAN A/Gb mode packet switched handover is introduced. Packet switched handover reduces the 
service interruption of the user plane information at cell change compared to the cell-reselection. In addition PS 
handover enable methods to improve buffer handling of user plane data in order to reduce packet loss at cell-change. 
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Scope 



The present document defines the stage-2 service description for packet switched handover in GERAN A/Gb mode. 
ITU-T Recommendation 1.130 [8] describes a three-stage method for characterisation of telecommunication services, 
and ITU-T Recommendation Q.65 [9] defines stage 2 of the method. The present document refers to packet switched 
handover in GERAN A/Gb mode, and therefore focuses on the corresponding radio protocol enhancements to the packet 
switched domain only i.e. when services are provided through the Gb interface. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
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• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 
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[8] ITU-T Recommendations 1.130: "Method for the characterization of telecommunication services 

supported by an ISDN and network capabilities of an ISDN". 

[9] ITU-T Recommendation Q.65: "The unified functional methodology for the characterization of 

services and network capabilities". 

[10] 3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN); BSS GPRS Protocol". 

[II] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 
across the Gn and Gp interface". 

[12] 3GPP TS 23.003: "Numbering, addressing and identification". 

[13] 3GPP TS 25.401: "UTRAN overall description". 
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[19] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[20] 3GPP TS 23.108: "Mobile radio interface layer 3 specification core network protocols; Stage 2 
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[26] 3GPP TS 45.010: "Radio subsystem synchronization". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

A/Gb mode: mode of operation of the MS when connected to the Core Network via GERAN and the A and/or Gb 
interfaces 

PFC subject to handover: refers to a PFC that is supported using packet switched handover, e.g. a PFC with 

conversational QoS class 

Whether a PFC needs handover or not is decided by the BSS. This decision criteria is not be standardized. 

3.2 Void 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ATM Asynchronous Transfer Mode 

BSC Base Station Controller 

BSS Base Station Sub-system 

BSSGP Base Station Subsystem GPRS Protocol 

BTS Base Transceiver Station 

CN part Core Network part 

CN Core Network 

CS Circuit Switched 

DTM Dual Transfer Mode 

EDGE Enhanced Data rates for GSM Evolution 

FLO Flexible Layer One 

GbolP Gb over IP 

GERAN GSM/EDGE Radio Access Network 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 

GTP GPRS Tunnelling Protocol 
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IMS IP Multimedia Subsystem 

IP Internet Protocol 

LLC Logical Link Control 

MAC Medium Access Control 

MS Mobile Station 

MSC Mobile Switching Centre 

MTU Maximum Transfer Unit 

PDP Packet Data Protocol 

PDTCH Packet Data Traffic CHannel 

PFC Packet Flow Context 

PPM Packet Flow Management 

PS Packet Switched 

PTCCH Packet Timing advance Control CHannel 

QoS Quality of Service 

RAB Radio Access Bearer 

RAN Radio Access Network 

RAT Radio Access Technology 

RAU Routeing Area Update 

RLC Radio Link Control 

RN part Radio Network part 

RNC Radio Network Controller 

ROHC RObust Header Compression 

RRM Radio Resource Management 

RTP Real Time Protocol 

SABM Set Asynchronous Balanced Mode 

SACCH Standalone Associated Control CHannel 

SAPI Service Access Point Identifier 

SGSN Serving GPRS Support Node 

SIP Session Initiated Protocol 

SNDCP Sub-Network Dependent Convergence Protocol 

TBF Temporary Block Flow 

TF Transport Format 

TFC Transport Format Combination 

TFCI Transport Format Combination Indicator 

TR Technical Report 

TS Technical Specification 

UA Unnumbered Acknowledgement 

UDP User Datagram Protocol 

UE User Equipment 

UMTS Universal Mobile Telephony System 

UTRAN UMTS Terrestrial Radio Access Network 

VoIP Voice over IP 

XID exchange IDentification 
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4 Architecture and principles 



4.1 Reference architecture 




Bold lines: 
Thin lines: 



Interfaces supporting user traffic; 
Interfaces supporting signalling. 



NOTE: The lu interface is also supported by a GERAN BSS supporting lu mode. 

Figure 1 : Reference Architecture for PS handover in GERAN A/Gb mode 

4.2 Handover principles 
4.2.1 General 

The PS Handover procedure is used to handover an MS with one or more packet flows from a source cell to a target 
cell. The source and target cells can be located within either the same BSS (Intra BSS HO), different BSSs within the 
same SGSN (Intra SGSN HO) or belonging to different SGSNs (Inter SGSN HO), or systems with different radio 
access types (Inter RAT HO, Inter mode HO). 
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While the MS is still in the source cell: 

• Radio resources in the target cell are allocated and signalled to the MS. 

• System information of the target cell is signalled to the MS. 

For each scenario (Intra BSS HO, Intra SGSN HO, Inter SGSN HO and Inter RAT/mode HO) the PS handover 
procedure is divided into: 

• a preparation phase; and 

• an execution phase. 

By using the Gs interface (together with NMOl) the interruption time for the PS Handover procedure would be 
shortened since using a combined LAU/RAU procedure would be possible. 

4.2.2 PS Handover preparation phase 

The PS handover preparation phase consists of the following consecutive steps: 

• the decision by the source BSS to request a PS handover for an MS with one or more PFCs subject to handover: 

the request from the source BSS to the old SGSN for the PS handover; 

- if the target BSS is not connected to the same SGSN the request from the old SGSN to the new SGSN to 
reserve resources; 

• the reservation of resources in the target network nodes prior to ordering the MS to move to the target cell. This 
involves: 

in case of Inter SGSN handover, the new SGSN reserving SNDCP/LLC resources and Packet Flow Contexts; 

in case of RA change the SGSN (which belongs to the RA) allocates a new P-TMSI and derives a new Local 
TLLI from this P-TMSI; 

the target BSS reserving/allocating radio resources and Packet Flow Contexts in the target cell. 

When handover has to be performed for an MS with multiple active PFCs, the SGSN requests the BSS to create one or 
more PFCs. If not all PFCs can be created successfully the target BSS indicates this to the new SGSN, which may then 
abort the handover. If no PFC can be created successfully the handover shall be aborted. 

The target BSS may or may not establish radio resources for the created PFCs. PFCs with no radio resources reserved 
will be re-established upon arrival in the target cell. If no radio resources at all are established the handover shall be 
aborted. 

4.2.3 PS Handover execution pinase 

The PS Handover execution phase consists of the following consecutive steps: 

• packet forwarding by the old SGSN of the received DL packets both to the source BSS, new SGSN (if Inter 
SGSN HO) and the target BSS as soon as radio resources are reserved in the target BSS; 

• the optional "blind" transmission by the target BSS of the DL RLC/MAC blocks over the reserved radio 
resources in the target cell is only valid for lossy type of services where unacknowledged LLC and RLC protocol 
modes are used; 

• the command generated by the target BSS/RNS sent via the source BSS to order the MS to handover to the target 
cell; 

• the notification by the MS of its presence in the target cell on the allocated radio resources; 

• the redirection by the SGSN of the DL packets to the target BSS alone; 

• the release of the resources on the source side including PFCs and radio resources. 
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4.2.4 PS Handover Network Node Responsibilities 

This clause would reflect the Agreed Handover principles from the clause A.l by listing the specific node 
responsibilities during PS handover. 

4.3 Protocol architecture 

This clause will contain information on the services and functions provided and required by each layer. 

4.3.1 User plane overview 

The user plane protocol architecture for GERAN A/Gb are depicted in figure 2. 




MS BSS SGSN GGSN 

Figure 2: User Plane protocol architecture in A/Gb mode 



4.3.2 Control plane overview 



Figure 3 shows the protocol architecture for the control plane required to support PS Handover in A/Gb mode. Protocol 
entities on the network side under BSSGP are not shown, as the architecture remains the same as for the legacy A/Gb 
mode. 
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Figure 3: Control Plane Architecture in A/Gb mode 
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4.3.3 Physical Layer 
4.3.3.1 Shared Channels 
4.3.3.1.1 General 

Radio resources on one or more shared channels may be assigned to an MS (according to its multislot capabiHties) for 
exchange of user plane payload for any PFC between the BSS and the MS. The key characteristics of a service realized 
using a shared channel are as follows: 

• RLC/MAC control messages are used to allocate the required uplink and downlink TBFs where both TBFs are 
associated with the same PFC and therefore are identified using the same PFI. 

• Handover initiation decisions are made by the BSS and may be based on measurement reports or cell change 
notification information sent by the mobile station on PACCH. 

• If the mobile station is allocated one or more shared channels in support of a PFC that is subject to handover, 
then the BSS may prohibit this MS from making autonomous cell re-selection decisions while that PFC is active. 

• After the MS has moved to the target cell, initial uplink access in this cell is controlled by USF scheduling. 

4.3.4 RLC/MAC 

The services required from the RLC/MAC layer are: 

• Data transfer in acknowledged mode. 

• Data transfer in unacknowledged mode. 

• Segmentation and reassembly. 

• In-Sequence delivery of LLC PDUs (for a given PFC). 

• Assignment, reconfiguration and release of TBFs and RLC instances (RLC/MAC control functions). 

• Control of timing advance. 

• Notification of unrecoverable errors to LLC. 

• Handling of RLC/MAC control messages. 

RLC/MAC services are required by radio resource management functions in order to send and receive messages to/from 
the MS and BSS relating to radio resource management. 

RLC/MAC supports the following radio resource management features that are required for PS handover: 

• Establishment of a TBF on one or more physical channel(s) in a given direction, for a given PFC. 

• Reconfiguration of the radio resources assigned to one or more TBFs in downlink and/or uplink within a cell. 

• Release of TBFs and associated radio resources following the corresponding service deactivation. 

• Release of all TBFs and associated radio resources in the source cell, as a result of handover to a target cell. 

4.3.5 Radio Resource (RR) 

This clause will contain information on any impacts on the RR protocol related to support of PS Handover. 

4.3.6 BSSGP 

BSSGP is expected to provide the signalling channel for PS Handover related signalling between the CN and the BSS. 
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The services required from the BSSGP layer can therefore be summarised as: 

• Transmission and reception of PS Handover related messages (i.e. PFM messages) over the Gb interface. 

• Routing of PS Handover related messages to the PFM entity. 

• Handling of PS Handover related messages with the appropriate priority. 

4.3.7 Overview of PS Handover Signalling Messages 

The signalling messages used during PS handover are divided into three groups depending on the utilized interface; 

• PS handover signalling messages on the Um interface are RLC/MAC signalling blocks. 

• PS handover signalling messages on the Gb interface are BSSGP signalling messages sent by the PFM entity. 

• PS handover signalling messages on the Gti interface are GTP signalling messages. 

4.3.7.1 PS handover signalling messages on the Um interface 

The signalling messages used on the Um interface are: 

• PS Handover Command (ESS -> MS). 

NOTE 1 : The existing Packet Cell Change Order (PCCO) message enhanced with the PS Handover related IE is a 
suitable message to be used as PS handover Command. 

• Packet Control Acknowledgement (MS -> BSS). 

• Packet Control Acknowledgement - Access Bursts (MS -> BSS). 

• Packet Uplink Assignment (BSS -> MS). 

• Packet (P)SI Status (MS -> BSS). 

NOTE 2: The signalling messages listed above are existing RLC/MAC signalling messages specified in 
3GPPTS 44.060 [7]. 

4.3.7.2 PS handover signalling messages on the Gb interface 

The Gb interface signalling messages are new signalling messages carried by the BSSGP. These signalling messages 
are to be defined in 3GPP TS 48.018 [10]. 

The signalling messages used on the Gb interface are: 

• PS Handover Required (B S S ->CN) : 

This message is sent from the BSS to the SGSN to indicate that for a given MS which already has radio 
resource(s) assigned, a PS handover is required. 

• PS Handover Request (CN->BSS): 

This message is sent from the SGSN to the target BSS to request the target BSS to reserve resources for the 
MS subject to PS Handover. 

• PS Handover Request Acknowledge (BSS->CN): 

This message is sent from the target BSS to the SGSN to report the outcome of the resource allocation for the 
requested BSS PFCs. 

• PS Handover Reject (BSS -> CN): 

This message is sent from the target BSS to the SGSN to report the failure of the resource allocation for the 
requested BSS PFCs. 
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• PS Handover Complete (BSS->CN): 

This message is sent from the target BSS to the SGSN to notify the MS of a successful access on the target 
cell. 

• PS Handover Command (CN->BSS): 

This message is sent from the SGSN to the source BSS to indicate that the MS can switch to the target cell. 

• PS Handover Cancel (BSS->CN): 

This message is sent from the BSS to the SGSN to inform the SGSN to abort an ongoing handover. 

• PS Handover Required Reject (CN->BSS): 

This message is sent from the SGSN to the BSS to inform unsuccessful resource allocation in the target cell. 

4.3.7.3 PS handover signalling messages on the Gn interface 

The Gn interface signalling messages are existing messages that will be used as described in 3GPP TS 29.060 [11]. 
The signalling messages used on the on the Gn interface between source SGSN and target SGSN are: 

• Forward Relocation Request: 

The old SGSN shall send a Forward Relocation Request message to the new SGSN to convey necessary 
information to perform the PS handover procedure between new SGSN and Target BSS. 

• Forward Relocation Response: 

The new SGSN shall send a Forward Relocation Response message to the old SGSN as a response to a 
previous Forward Relocation Request message. 

• Forward Relocation Complete: 

The new SGSN shall send a Forward Relocation Complete message to the old SGSN to indicate that the PS 
Handover procedure has been successfully finished. 

• Forward Relocation Complete Acknowledge: 

The old SGSN sends a Forward Relocation Complete Acknowledge message to the new SGSN as a response 
to Forward Relocation Complete message. 

• Relocation Cancel Request: 

The Relocation Cancel Request message is sent from the old SGSN to the new SGSN when the old SGSN is 
requested to cancel the PS Handover procedure by the source BSS by means of BSSGP message. 

• Relocation Cancel Response: 

The Relocation Cancel Response message is sent from the new SGSN to the old SGSN when the PS 
handover procedure has been cancelled in the old SGSN. This message is used as the response to the 
Relocation Cancel Request message. 

GTP messages need to be enhanced with additional IE to support PS Handover. 

4.4 Identifiers 

The identifiers used in PS handover for GERAN A/Gb mode are the identities used by MS to connect via GERAN 
through the Gb interface as well as through the lu interface to the Core Network. 

A large number of these identities for GERAN A/Gb mode will be utilized in the PS handover procedure in GERAN 
A/Gb mode in the same manner as specified currently. However in order to support PS handover procedure new 
identifiers will be defined as well. 
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In order to enable data transmission and to address the resources allocated by the target system during the PS Handover 
procedure (i.e. for the case where the target cell belongs to another RA), before the MS moves to the target cell a new 
P-TMSI will be allocated by the SGSN associated with the RA the target cell belongs to. The new P-TMSI is a 
temporary and unique identifier in the new RA and is used to assign a local TLLI for the target cell. 

NOTE: Further in this TS the term "local TLLI" refers to the Local TLLI derived from new P-TMSI assigned by 
the new SGSN and utilized in the target cell, whereas the term "old TLLI" refers to the Local TLLI 
utilized in the source cell that is derived from the P-TMSI assigned by the old SGSN. 

In case of inter RAT PS Handover to/from UTRAN and inter-mode handover to/from GERAN lu mode, existing 
UTRAN and GERAN lu mode identifiers will be used. 

The existing as well as new identifiers utilized in PS handover procedure for GERAN A/Gb mode are listed in table 1 . 
Table 1 : Identifiers utilized in PS handover in GERAN /AGb 



Identifier 


Specification reference 


CI (Cell Identity) 


3GPP TS 23.003 [12], 3GPP TS 25.401 [13], 
3GPPTS 43.051 [14] 


RAI (Routing Area Identity) 


3GPPTS 23.003 [12] 


LAI (Location Area Indentity) 


3GPPTS 24.008 [15] 


IMSI (International IVIobile Subscriber Identity) 


3GPPTS 23.003 [12] 


P-TMSI_(Packet Temporary IVIobile Subscriber Identity) 


3GPPTS 23.003 [12] 


TLLI (Temporary Logical Link Identity) 


3GPPTS 23.003 [12] 


RNTI(Radio Network Temporary Identity) 


3GPP TS 44.1 18 [1 6], 3GPP TS 25.401 [13] 


GRNTI (GERAN Radio Network Temporary Identity) 


3GPPTS 25.401 [13] 


U-RNTI (UTRAN-RNTI) 


3GPPTS 25.401 [13] 


TEID (Tunnel Endpoint Identifier) 


3GPPTS 29.060 [11] 


NSAPI (Network Service Access Point Identifier) 


3GPPTS 29.060 [11] 


Tl (Transaction Identifier) 


3GPPTS 24.007 [18] 


SAPI (Service Access Point Identifier) 


3GPPTS 29.060 [11] 


PFI (Packet Flow Identifier) 


3GPPTS 48.018 [10] 


BVCI (BSSGP Virtual Connection Identifier) 


3GPPTS 48.018 [10] 


RAB Id (Radio Access Bearer Identifier) 


3GPPTS 25.331 [17] 


RB Id (Radio Bearer Identifier) 


3GPPTS 25.331 [17] 


TFI (Temporary Flow Identity) 


3GPP TS 44.060 [7] 


USF (Uplink State Flag) 


3GPP TS 44.060 [7] 


PS handover Reference 


Existing 3GPP TS 44.01 8 [1 0]/ To be Specified 



The description of the new identifier is given below: 
• PS Handover Reference. 

PS Handover Reference is equivalent to handover reference in GSM, which is needed during PS Handover in GERAN 
A/Gb mode for reliability in order to prevent BSS overhearing other MSs access bursts, so as to identify the MS 
accessing the assigned resources. Handover Reference in GSM can be used as PS handover Reference 
(3GPP TS 44.018 [10]) during PS handover procedure or optionally PS handover reference can be defined specifically 
for PS handover procedure. 

4.4.1 NSAPI, PFI, RAB ID relation during inter-RAT, inter-mode PS 
handover 

During the inter-RAT and inter-mode PS handover to/from UTRAN/GERAN lu there is a need to associate the MSs 
active PDP context with the BSS PFC and RABs in the respective SGSN(s). 

As depicted in 3GPP TS 23.060 [19] NSAPI is a common identifier of the PDP context in all systems and as such it can 
be used by the MS to associate the active PDP contexts to the BSS PFC identified by the PFI and the RAB identified by 
the RAB Id during the inter-mode and inter-RAT PS handover. The MS has to associate the BSS PFC identified by the 
PFI utilized in GERAN A/Gb mode cell with a RAB identified by RAB Id utilized in the UTRAN /GERAN lu mode 
cell. This is done through the relation with the NSAPI, which is the common identifier in both systems. MS performs 
this association based on the identifiers received by the network. 
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The information received by the MS/UE depends on the RAT of the target cell. In case of the GERAN lu mode target 
cell and GERAN A/Gb mode source cell, the MS shall receive the RAB Id and associate this with its existing PFIs 
based on the relation with NS API. In case of the GERAN A/Gb mode target cell, GERAN lu mode source cell, the UE 
shall receive the PFI for each of the accepted NS APIs and may receive the NSAPI / SAPI / PFI association for the case 
when the old SGSN did not have these values available and the new SGSN has assigned new values. The MS shall 
associate its RAB Ids to the respective SAPI and PFI based on the relation with NSAPI. 



Signalling procedures 



The signalling procedures will be updated once the Um signalling messages has been agreed. 

5.1 GERAN (A/Gb) ^ GERAN (A/Gb) handover 

5.1.1 Intra Cell 

Intra Cell PS Handover will be needed in cases when a new channel is selected in the same cell to be used by the MS. 
This is handled by the BSS internally and if there are no changes in the new channel there is no need for BSS to notify 
the SGSN about the change of channel. 

BSS/SGSN signalling will be needed in case the new channel has limited resources and cannot support the same QoS, 
for the BSS PEC as the old channel. 

For these purpose existing modification procedures on the Um and Gb interface are used, e.g. PACKET TIMESLOT 
RECONFIGURE (3GPP TS 44.060 [7]) on the air interface and MODIFY BSS PEC (3GPP TS 48.018 [10]) procedure 
on the Gb interface. 

If the modification procedures fail BSS may cancel the intra cell PS handover procedure. 

5.1.2 Intra BSS 



5.1.2.1 



General 



This clause is further split into two clauses. The first describes an intra-BSS handover procedure based largely on the 
inter-BSS handover procedure. The second section describes an optional optimised intra-BSS handover procedure. 
When the source and target cells are within the same BSS the handover can be either executed by the BSS itself 
(optimised handover) or by involving the SGSN. In the latter case although handover is performed within one BSS the 
roles of source BSS and target BSS are the same as in Inter BSS Handover. 



5.1.2.2 



Intra BSS HO; Preparation phase 



MS 
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Figure 4: PS Handover Preparation Phase; Intra-BSS case (GERAN A/Gb ^ GERAN A/Gb) 



£75/ 



3GPP TS 43.129 version 6.1.0 Release 6 



18 



ETSI TS 143 129 V6.1.0 (2005-01) 



1. The BSS decides to initiate a PS handover. At this point both uplink and downhnk user data is transmitted via 
the following: TBFs between the MS and BSS, BSSGP PFCs tunnel(s) between the BSS and SGSN, GTP 
tunnel(s) between the SGSN and GGSN. 

2. The BSS sends a PS Handover Required (TLLI, Cause, Source Cell Identifier, Target Cell Identifier, Source 
BSS to Target BSS Transparent Container [RN part]) message to the SGSN. 

3. The SGSN determines from the Target ID the type of handover, i.e. intra-SGSN, inter-SGSN or inter-RAT/mode 
handover. In case of Intra-SGSN PS handover, the SGSN sends a PS Handover Request (TLLI, Cause, IMSI, 
Source Cell Identifier, Target Cell Identifier, PFCs To Be Set Up List, Source BSS to Target BSS Transparent 
Container [RN part]) message to the BSS. The SGSN shall not request resources for PFCs associated with PDP 
contexts with a maximum bit rate for uplink and downlink of kbit/s. 

NOTE: The BSS PFCs required to be set up are downloaded to the target BSS from the SGSN, i.e. all information 
required for PFC creation. 

4. Based upon the ABQP for each PFC the BSS makes a decision about which PFCs to assign radio resources. The 
algorithm by which the BSS decides which PFCs that need resources is implementation specific. Due to resource 
limitations not all downloaded PFCs will necessarily receive resource allocation. The BSS allocates TBFs for 
each PFC that can be accommodated. 

After allocating radio resources the target BSS shall prepare the Target BSS to Source BSS Transparent 
Container for the set up BSS PFCs. 

5. The BSS shall send the PS Handover Request Acknowledge (TLLI, Cause, PFCs Set Up/Failed to Set Up, 
Target BSS to Source BSS Transparent Container [RN part, CN part]) message to the SGSN for the accepted 
PFCs. Upon sending the PS Handover Request Acknowledge message the BSS shall be prepared to receive 
downlink LLC PDUs directed to the new cell and associated with the accepted PFCs. 

When the SGSN receives the PS Handover Request Acknowledge message and it decides to proceed with the 
handover, the preparation phase is finished and the execution phase will follow. 



5.1.2.3 



Intra BSS HO; Execution phase 
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Figure 5: PS Handover Execution Phase; Intra-BSS case (GERAN A/Gb -^ GERAN A/Gb) 

1 . The SGSN continues to receive GTP packets from the GGSN (via GTP) and forwards the associated PDU 
payload to the MS via the BSS. 

When receiving the PS Handover Request Acknowledge message the SGSN may, based on QoS, start 
duplication of LLC PDUs and forward those to the new cell in the BSS. If the SGSN forwards downlink packets 
to the new cell in the BSS, the BSS may start blind transmission of downlink user data towards the MS over the 
allocated radio channels. 
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2. The SGSN continues the PS Handover by sending a PS Handover Command (TLLI, Cause, PFCs To Be Set 
Up List, Target BSS to Source ESS Transparent Container [RN part, CN part]) message to the source BSS. 

Before sending the PS Handover Command message, the SGSN based on QoS, suspends downhnk data 
transfer for PDF contexts, which are sensitive to packet loss. 

Before sending the PS Handover Command message to the MS the BSS, based on QoS, tries to empty the 
downlink BSS buffer for BSS PFCs, which are sensitive to packet loss. 

The BSS receiving the PS Handover Command message stops the uplink traffic, based on QoS, for flows, 
which require delivery order to be preserved. 

NOTE 1: Only PFI(s) for PFCs accepted by the target cell are included in the message. 

3. The BSS sends the PS Handover Command (Handover Reference, Target BSS to Source BSS Transparent 
Container [RN part, CN part]) message to the MS by interrupting the transmission of LLC PDUs on any of the 
downlink TBFs. Following the transmission of this signalling message the BSS immediately resumes LLC PDU 
transmission until it either has no more LLC PDUs to send or the PFC is released. MS management of uplink 
N-PDUs following the reception of the PS Handover Command message is as follows: 

• All uplink packets associated with a PFC receiving handover treatment that have not yet been fully 
transmitted might be buffered depending on the QoS class. 

• Subsequent uplink packets that become available for transmission following the reception of the PS 
Handover Command message might also be buffered depending on the QoS class. 

• The MS may discard uplink packets during the link interruption to preserve the real-time properties. 

4. The MS tunes to the radio channel and the timeslot allocated in the target cell by the BSS and sends the PS 
Handover Access (Handover Reference) message in the form of four handover access bursts to the BSS on the 
allocated channel. The PS Handover Command message may indicate that the PS Handover Access message 
is optional to send by the MS. 

5. The BSS sends a Physical information message (see 3GPP TS 23.108 [20]) to the MS for the MS to 
synchronize. 

NOTE 2: In the synchronised networks case the MS receives the timing advance information to use in uplink in the 
target cell in the PS Handover Command message. In this case the sending of the Physical information 

message in the target cell is omitted. 

6. In case the target cell is within the same routing area as the source cell, the MS sends an arbitrary LLC frame to 
the SGSN, which in the SGSN is interpreted as an implicit cell update. In case the target cell is within another 
routing area, the MS sends a Routing Area Update Request message to the SGSN. To make the handover 
interruption short the MS sends this message immediately after receiving the Physical Information message or, 
in the synchronised network case, immediately after the sending of the PS Handover Access message. 

7. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the BSS sends a 
PS Handover Complete (TLLI, Handover Complete Status) message to inform the PFM entity in the SGSN 
that the MS has arrived in the target cell. The source BSS initiates the release of the radio resources in the source 
cell. After the reception of the PS Handover Complete message the SGSN shall be prepared to receive data 
from the new cell. 

5.1 .2.4 Intra BSS Handover - Optimised 

This clause describes the optimised intra-BSS PS handover procedures applicable for the case where the source and 
target cells are associated with the same Network Service Entity (NSE) and the same Routing Area (RA). The 
optimisation involves the BSS providing the data forwarding function and does not require any explicit signalling with 
the SGSN. Support for this procedure is optional for the BSS. 

Supporting this procedure requires that the BSS be able to determine whether or not it manages PS resources for the 
target cell, whether or not the target cell is associated with the same NSE, that it can internally forward LLC PDUs from 
the source to the target cell and whether or not both cells are part of the same RA (i.e. the SGSN is not required to make 
this determination and relay this information). If the BSS cannot make these determinations it shall use the non- 
optimised intra-BSS PS handover procedures described in clauses 5.L2.2 and 5.L2.3. 
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NOTE: Since the transfer of LLC PDUs at PS handover are performed within the same BSS, the Source BSS to 
Target BSS Transparent Container and the Target BSS to Source BSS Transparent Container are not 
created in this scenario. 



MS 
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PS handover 
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Figure 6: Optimised Intra-BSS PS IHandover (same NSE and same RA) 

1 . The BSS decides that a handover is required based on received measurement reports. 

2. The BSS determines that it manages resources for both cells and that they are associated with the same (NSE) 
and the same RA. The BSS applies data forwarding (from the old cell to the new cell) for PFCs that it determines 
are to receive PS handover treatment. 

NOTE 1 : The MS does not know if optimised or non-optimised intra-BSS PS handover procedures are used. 

3. The BSS sends the PS Handover Command (Handover Reference, Target BSS to Source BSS Transparent 
Container [RN part, CN part]) message to the MS by interrupting the transmission of LLC PDUs on any of the 
downlink TBFs. Following the transmission of this signalling message the BSS immediately resumes LLC PDU 
transmission until it either has no more LLC PDUs to send or the PEC is released. MS management of uplink 
N-PDUs following the reception of the PS Handover Command message is as follows: 

• All uplink packets associated with a PEC receiving handover treatment that have not yet been fully 
transmitted might be buffered depending on the QoS class. 

• Subsequent uplink packets that become available for transmission following the reception of the PS 
Handover Command message might also be buffered depending on the QoS class. 

• The MS may discard uplink packets during the link interruption to preserve the real-time properties. 

4. The MS tunes to the radio channel and the timeslot allocated in the target cell by the BSS and sends the PS 
Handover Access (Handover Reference) message in the form of four handover access bursts) to the BSS on the 
allocated channel. The PS Handover Command message may indicate that the PS Handover Access message 
is optional to send by the MS. 
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5. The BSS sends a Physical information message (see 3GPP TS 23.108 [20]) to the MS to synchronise. 

NOTE 2: In the synchronised networks case the MS receives the timing advance information to use in uplink in the 
target cell in the PS Handover Command message. In this case the sending of the Physical information 

message in the target cell is omitted. 

6. The MS sends an arbitrary LLC frame to the SGSN, which in the SGSN is interpreted as an implicit cell update. 
To make the handover interruption short the MS sends this message immediately after receiving the Physical 
Information message or, in the synchronised network case, immediately after the sending of the PS Handover 
Access message. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS 
the BSS releases the radio resources in the source cell. The reception of the Cell Update message at the SGSN 
triggers the sending of downlink data to the new cell using a new B VCI if it is addressed by a different B VCI. 

7. The SGSN responds to the Cell Update with a FLUSH-LL message. 

8. The BSS returns the FLUSH-LL_ACK message indicating if unsent LLC PDUs have been deleted or transferred 
to the new cell. If the BSS supports forwarding of LLC PDUs to the new cell it may indicate (within the 
FLUSH-LL_ACK message) that unsent LLC PDUs have been transferred. This is however implementation 
specific for the BSS. 

9. The first DL PDU received by the BSS with the new-BVCI allows the BSS to clear the relationship to the old 
BVCI. 

NOTE 3: It is assumed here that downlink flow control is carried out on a per PEC basis and that the PEC specific 
flow control parameters remain the same upon MS arrival in the target cell. 

5.1.3 Intra SGSN 
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Figure 7: PS Handover Preparation Phiase; Intra-SGSN/lnter-BSS case (GERAN A/Gb ^ GERAN A/Gb) 

1. The source BSS decides to initiate a PS handover. At this point both uplink and downlink user data is transmitted 
via the following: TBEs between MS and source BSS, BSSGP PECs tunnel(s) between the source BSS and 
SGSN, GTP tunnel(s) between the SGSN and GGSN. 

2. The source BSS sends a PS Handover Required (TLLI, Cause, Source Cell Identifier, Target Cell Identifier, 
Source BSS to Target BSS Transparent Container [RN part]) message to the SGSN. 

3. The SGSN determines from the Target ID the type of handover, i.e. intra-SGSN, inter-SGSN or inter-RAT/mode 
handover. In case of Intra-SGSN PS handover, the SGSN sends a PS Handover Request (TLLI, Cause, IMSI, 
Source Cell Identifier, Target Cell Identifier, PECs To Be Set Up List, Source BSS to Target BSS Transparent 
Container [RN part]) message to the target BSS. The SGSN shall not request resources for PECs associated with 
PDP contexts with a maximum bit rate for uplink and downlink of kbit/s. 
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NOTE 1: The BSS PFCs required to be set up are downloaded to the target BSS from the SGSN, i.e.all information 
required for PFC creation. 

NOTE 2: The XID Command message is not included in the PS Handover Request message in case of Intra-SGSN 
PS Handover, and thus the PS Handover BSS PFC Status Report message shall never be sent in this 

case. 

4. Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio 
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. 
Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS 
allocates TBFs for each PFC that can be accommodated by the target BSS. 

After allocating radio resources the target BSS shall prepare the Target BSS to Source BSS Transparent 
Container for the set up BSS PFCs. 

5. The target BSS sends the PS Handover Request Acknowledge (TLLI, Cause, PFCs Set Up/Failed to Set Up, 
Target BSS to Source BSS Transparent Container [RN part, CN part]) message to the SGSN for the accepted 
PFCs. Upon sending the PS Handover Request Acknowledge message the target BSS shall be prepared to 
receive downlink LLC PDUs from the SGSN for the accepted PFCs. 

When the SGSN receives the PS Handover Request Acknowledge message and it decides to proceed with the 
handover, the preparation phase is finished and the execution phase will follow. 



5.1.3.2 
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Figure 8: PS Handover Execution Phase; Intra-SGSN/lnter-BSS case (GERAN A/Gb ^ GERAN A/Gb) 

1. The SGSN continues to receive GTP packets from the GGSN (via GTP) and forwards the associated PDU 
payload to the MS via the source BSS. 

2. When receiving the PS Handover Request Acknowledge message the SGSN may, based on QoS, start 
duplication of LLC PDUs and forward those to the target BSS. If the SGSN forwards downlink packets to the 
target BSS, the target BSS may start blind transmission of downlink user data towards the MS over the allocated 
radio channels. 

3. The SGSN continues the PS Handover by sending a PS Handover Command (TLLI, Cause, PFCs To Be Set 
Up List , Target BSS to Source BSS Transparent Container [RN part, CN part,]) message to the source BSS. 

Before sending the PS Handover Command message, the SGSN based on QoS, suspends downlink data 
transfer for PDP contexts, which are sensitive to packet loss. 
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Before sending the PS Handover Command message to the MS the source BSS, based on QoS, tries to empty 
the downhnk BSS buffer for BSS PFCs, which are sensitive to packet loss. 

The source BSS receiving the PS Handover Command message stops the upHnk traffic, based on QoS, for 
flows, which require delivery order to be preserved. 

NOTE 1: Only PFI(s) for PFCs accepted by the target cell are included in the message. 

4. The source BSS sends the PS Handover Command (Handover Reference, Target BSS to Source BSS 
Transparent Container [RN part, CN part]) message to the MS by interrupting the transmission of LLC PDUs on 
any of the downlink TBFs. Following the transmission of this signalling message the source BSS immediately 
resumes LLC PDU transmission until it either has no more LLC PDUs to send or the PFC is released. MS 
management of uplink N-PDUs following the reception of the PS Handover Command message is as follows: 

• All uplink packets associated with a PFC receiving handover treatment that have not yet been fully 
transmitted might be buffered depending on the QoS class. 

• Subsequent uplink packets that become available for transmission following the reception of the PS 
Handover Command message might also be buffered depending on the QoS class. 

• The MS may discard uplink packets during the link interruption to preserve the real-time properties. 

5. The MS tunes to the radio channel and the timeslot allocated in the target cell by the BSS and sends the PS 
Handover Access (Handover Reference) message in the form of four handover access bursts to the BSS on the 
allocated channel. The PS Handover Command message may indicate that the PS Handover Access message 
is optional to send by the MS. 

6. The target BSS sends a Physical information message (see 3GPP TS 23.108 [20]) to the MS for the MS to 
synchronise. 

NOTE 2: In the synchronised networks case the MS receives the timing advance information to use in uplink in the 
target cell in the PS Handover Command message. In this case the sending of the Physical information 

message in the target cell is omitted. 

7. In case the target cell is within the same routing area as the source cell, the MS sends an arbitrary LLC frame to 
the SGSN, which is interpreted as a cell update to the SGSN. In case the target cell is within another routing 
area, the MS sends a Routing Area Update Request message to the SGSN. To make the handover interruption 
short the MS sends this message immediately after receiving the Physical Information message or, in the 
synchronised network case, immediately after the sending of the PS Handover Access message. 

8. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the target BSS 
sends a PS Handover Complete (TLLI, Handover Complete Status) message to inform the PFM entity in the 
SGSN that the MS has arrived in the target cell. The source BSS initiates the release of the radio resources in the 
source cell. After the reception of the PS Handover Complete message the SGSN shall be prepared to receive 
data from the new cell. 
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5.1.4 Inter SGSN 
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Figure 9: PS Handover Preparation Phiase; Inter-SGSN case (GERAN A/Gb ^ GERAN A/Gb) 

1. The source BSS decides to initiate a PS handover. At this point both uplink and downlink user data is transmitted 
via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between source BSS and old 
SGSN, GTP tunnel(s) between old SGSN and GGSN. 

2. The source BSS sends a PS Handover Required (Old TLLI, Cause, Source Cell Identifier, Target Cell 
Identifier, Source BSS to Target BSS Transparent Container [RN part]) message to the old SGSN. 

3. The old SGSN determines from the Target ID the type of handover, i.e. intra-SGSN, inter-SGSN or inter- 
RAT/mode handover. In case of inter-SGSN PS Handover, the old SGSN initiates the PS Handover resource 
allocation procedure by sending a Forward Relocation Request (IMSI, Cause, Source Cell Identifier, Target 
Cell Identifier, MM Context, PDP Contexts, Packet Flow ID, SNDCP XID parameters, LLC XID parameters. 
Tunnel Endpoint Identifier Control Plane, SGSN Address, Source BSS to Target BSS Transparent Container 
[RN part], PDP Context Prioritisation) message to the new SGSN. The old SGSN sends all active PDP contexts 
to the new SGSN indicating the PFIs and the XID parameters related to those PDP contexts. 

As part of the MM context the following security related information is included: 



Kc 

CKSN 

Used Cipher 

MS Network CapabiUty 



Ciphering key for GPRS. 
Ciphering Key Sequence Number of Kc. 
Selected ciphering algorithm for GPRS (GEA). 
Includes ciphering algorithms supported by the MS. 



The Ciphering key used by the old SGSN is reused by the new SGSN until a new authentication procedure is performed 
(see clause 5.1.4.2, bullet 13). 

If the new SGSN does not support the indicated ciphering algorithm, the new SGSN has to select a new ciphering 
algorithm. This new algorithm will be sent transparently from the new SGSN to the MS. The lOV-UI parameter 
generated in the new SGSN and used as input to the ciphering procedure will also be transferred transparently from the 
new SGSN to the MS. 
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When the new SGSN receives the Forward Relocation Request message it extracts from the PDP Contexts the 
associated NSAPIs, SAPIs and PFIs to be used in the new SGSN. In case when the new SGSN does not support the 
same SAPI and PFI for a certain NSAPI as the old SGSN, the new SGSN shall continue the PS handover procedure 
only for those NSAPIs for which it can support the same PFI and SAPI as the old SGSN and for which it can allocate 
resources. All PDP contexts for which no resources are allocated by the new SGSN or for which it cannot support the 
same SAPI and PFI (i.e. the corresponding NSAPIs are not addressed in the Forward Location Response message of the 
target SGSN), are maintained in the new SGSN and the related SAPIs and PFIs are kept. When this occurs the packet 
data transfer corresponding to PDP Contexts for which new SAPI and PFI values are needed are suspended. These PDP 
contexts may be modified or deactivated by the new SGSN via explicit SM procedures upon the completion of the 
routing area update (RAU) procedure. When the required PDP, MM, SNDCP and LLC contexts are established and the 
mapping between N-SAPI, SAPI and PFI for each of these PDP Contexts is established, the corresponding packet data 
transfer can continue. 

NOTE 1: XID parameters shall be sent from the old SGSN to the new SGSN and indicate the current XID 
parameter settings (i.e. those used at the old SGSN). 

• If the new SGSN can accept all XID parameters in use for a given N-SAPI it may send a corresponding XID 
Command that indicates the same XID parameters and new lOVs to the target BSS. 

• If the new SGSN can't accept any of the XID parameters in use for a given N-SAPI it may send a 
corresponding XID Command that indicates new XID parameters and new lOVs to the target BSS. 

• If the new SGSN can't accept some of the XID parameters in use for a given N-SAPI it may send a 
corresponding XID Command that indicates the same XID parameters for those that could be accepted and 
new ones for those that could not be accepted, and new lOVs to the target BSS. 

If the new SGSN does not execute any of the above three alternatives it shall instead send an XID Command indicating 
Reset and new lOVs to the target BSS. 

NOTE 2: The handhng of XID negotiation is as specified in 3GPP TS 44.064 [21]. 

4. In case of Inter-SGSN PS handover, the new SGSN sends a PS Handover Request (Local TLLI, Cause, IMSI, 
Source Cell Identifier, Target Cell Identifier, Source BSS to Target BSS Transparent Container [RN part], PFCs 
To Be Set Up List, XID Command) message to the target BSS. The new SGSN shall not request resources for 
PFCs associated with PDP contexts with a maximum bit rate for uplink and downlink of kbit/s. 

NOTE 3: The BSS PFCs required to be set up are downloaded to the target BSS from the new SGSN, i.e. all 
information required for PEC creation. 

NOTE 4: For each N-SAPI associated to a PEC in the PFCs To Be Set Up List, the new SGSN shall provide an 
XID Command. 

5. Based upon the ABQP for each PEC the target BSS makes a decision about which PFCs to assign radio 
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. 
Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target 
BSS allocates TBEs for each PEC that can be accommodated by the target BSS. 

6. If the target BSS is not able to allocate resources for one or more BSS PFCs it shall send a PS Handover 
Status Report (Setup PEC, Failed to Setup PFCs) message to the new SGSN. 

7. Upon receiving the PS Handover BSS PFC Status Report message the new SGSN sends the XID Command 
for each of the set up PFCs to the target BSS in the PS Handover BSS PFC Status Report Acknowledge 
(XID Command for the set up BSS PFC) message. 

8. After receiving all the necessary information for the accepted PFCs the target BSS shall prepare the Target BSS 
to Source BSS Transparent Container including the XID Commands only for the set up BSS PFCs. 

9. The target BSS shall send the PS Handover Request Acknowledge (Local TLLI, Cause, PFCs Setup/Failed to 
Setup, Target BSS to Source BSS Transparent Container [RN part, CN part,]) message to the new SGSN for the 
accepted PFCs. Upon sending the PS Handover Request Acknowledge message the target BSS shall be 
prepared to receive downlink LLC PDUs from the new SGSN for the accepted PFCs. 
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10. When the new SGSN receives the PS Handover Request Acknowledge message the Forward Relocation 

Response (IMSI, Cause, NSAPI(s), Target BSS to Source BSS Transparent Container [RN part, CN part], 
UTRAN Transparent Container, Tunnel Endpoint Identifier Control Plane, SGSN Address, Tunnel Endpoint 
Identifier Data II) message is sent from the new SGSN to the old SGSN. This message indicates that the new 
SGSN is ready to receive packets forwarded from the old SGSN. If the target BSS or the new SGSN failed to 
allocate resources this shall be indicated in the message. The Tunnel Endpoint Identifier Data II, one 
information for each PDF context, contains the tunnel endpoint of the new SGSN and the IP address of the new 
SGSN for data forwarding from the old to the new SGSN. 

The new SGSN activates the allocated LLC/SNDCP engines using initial sequence numbers of zero. 

When the old SGSN receives the Forward Relocation Response message and it decides to proceed with the 
handover, the preparation phase is finished and the execution phase will follow. 
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Figure 10: PS Handover Execution Phase; Inter-SGSN case (GERAN A/Gb ^ GERAN A/Gb) 
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1 . The old SGSN continues to receive GTP packets from the GGSN (via GTP) and forwards the associated PDU 
payload to the MS via the source BSS. 

2. If a Tunnel Endpoint is available the old SGSN may, based on QoS, start N-PDU relay and duplication to the 
new SGSN. 

• For each PDP context which uses LLC ABM in the old SGSN, all new downlink N-PDUs received after 
completion of the PS handover preparation phase are relayed to the new SGSN and the transmitted but not 
yet acknowledged downlink N-PDUs are duplicated and routed to the new SGSN. All such N-PDUs are 
encapsulated in a GTP-PDU when transmitted to the new SGSN together with their related N-PDU number. 

• For PDP context which uses LLC ADM in the old SGSN all new downlink N-PDUs received after 
completion of the PS handover preparation phase are relayed to the new SGSN. All such N-PDUs are 
encapsulated in a GTP-PDU when transmitted to the new SGSN. 

NOTE 1 : The order of steps, starting from step 2 onwards, does not necessarily reflect the order of events. For 
instance the old SGSN may start data forwarding (step 2), send the PS Handover Command message 
(step 4) and send the Forward SRNS Context message (step 4a) almost simultaneously. 

3. The new SGSN may, based on QoS, proceed with the packet handling as follows: 

• For PDP context(s) which uses LLC ABM the new SGSN stores the N-PDUs associated with their number 
into the SNDCP queue. Data transfer prior the exchange of N-PDU SNs is not possbile. 

• For PDP context(s) which uses LLC ADM the new SGSN either 

a. forwards the received downlink N-PDUs to the target BSS; 

b. stores the received data into the SNDCP queue for e.g. the PDU lifetime; 

c. discards the received data until e.g. reception of the PS Handover Complete message. 

If the new SGSN forwards downlink packets to the target BSS, the target BSS may start a blind transmission of 
downlink user data towards the MS over the allocated radio channels. 

4. The old SGSN continues the PS Handover by sending a PS Handover Command (Old TLLI, Cause, PFCs To 
Be Set Up List, Target BSS to Source BSS Transparent Container [RN part, CN part]) message to the source 
BSS. 

Before sending the PS Handover Command message, the old SGSN based on QoS, suspends downlink data 
transfer: 

• for PDP contexts, which require delivery order to be preserved; and 

• for PDP contexts, which are sensitive to packet loss. 

Before sending the PS Handover Command message to the MS the source BSS, based on QoS, tries to empty 
the downlink BSS buffer: 

• for BSS PFCs, which require delivery order to be preserved; and 

• for BSS PFCs, which are sensitive to packet loss. 

The source BSS receiving the PS Handover Command message stops the UL traffic, based on QoS, for 
flows, which require delivery order to be preserved. 

NOTE 2: Only PFI(s) for PFCs accepted by the target cell are included in the message. 
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4a. The old SGSN shall send the Forward SRNS Context (Send N-PDU number, Receive N-PDU number, DL 
GTP-U number, UL GTP-U number) message to the new SGSN if there is at least one PDP context which 
either requires "delivery order" to be preserved or which uses LLC ABM. The Forward SRNS Context 
message is then acknowledged by the Forward SRNS Context Acknowledge message. The Forward SRNS 
Context message contains the sequence numbers of the GTP-PDU next to transmitted in the uplink and 
downlink direction and the next N-PDU number that would have been used to send and receive data from the 
MS. 

The N-PDU sequence numbers are only sent by the old SGSN for PDP contexts, which uses LLC ABM. The 
GTP-U sequence numbers are only sent by the old SGSN for PDP context(s) requiring delivery order (QoS 
profile) to be preserved. If delivery order is to be preserved (QoS) profile), consecutive GTP-PDU sequence 
numbering shall be maintained through the lifetime of the PDP context(s). 

Therefore, during the entire PS Handover procedure for the PDP context(s) using delivery order required (QoS 
profile), the responsible GTP-U entities (SGSNs and GGSN) shall assign consecutive GTP-PDU sequence 
numbers to user packets belonging to the same PDP context uplink and downlink, respectively. 

From now on the new SGSN uses: 

• the initial N-PDU sequence number of zero for each activated SNDCP engine for LLC ADM; 

• the N-PDU sequence number provided by the old SGSN in the Forward SRNS context procedure for each 
activated SNDCP engine for LLC ABM. 

5. The source BSS sends the PS Handover Command (Handover Reference, Target BSS to Source BSS 
Transparent Container [RN part, CN part]) message to the MS by interrupting the transmission of LLC PDUs 
on any of the downlink TBFs. Following the transmission of this signalling message the source BSS 
immediately resumes LLC PDU transmission until it either has no more LLC PDUs to send or the PFC is 
released. Upon reception of the PS Handover Command the MS shall suspend the uplink transmission of user 
plane data. The MS management of uplink N-PDUs following the reception of the PS Handover Command 
message is as follows: 

• All uplink packets associated with a PFC receiving handover treatment that have not yet been fully 
transmitted might be buffered depending on the QoS class. 

• Subsequent uplink packets that become available for transmission following the reception of the PS 
Handover Command message might also be buffered depending on the QoS class. 

• The MS may discarded uplink packets during the link interruption to preserve the real-time properties. 

6. The MS tunes to the radio channel and the timeslot allocated in the target cell by the target BSS and sends the 
PS Handover Access (Handover Reference) message in the form of four handover access bursts to the target 
BSS on the allocated channel. The PS Handover Command message may indicate that the PS Handover 
Access message is optional to send by the MS. The target BSS sends a Physical information message (see 
3GPP TS 23.108 [20]) to the MS for the MS to synchronise. 

NOTE 3: In the synchronised networks case the MS receives the timing advance information to use in uplink in the 
target cell in the PS Handover Command message. In this case the sending of the Physical Information 

message in the target cell is omitted. 

7. The MS sends one XID Response message to the new SGSN for each XID Command message received in 
the source cell, thereby informing the SGSN about the negotiated security parameters. For LLC ABM, the XID 
Response message is followed by a SABM-UA exchange procedure as defined in TS 44.064. To make the 
handover interruption short the MS sends this message immediately after receiving the Physical Information 
message or, in the synchronised network case, immediately after the sending of the PS Handover Access 
message. 

After successful XID negotiation the MS shall resume the user data transfer only for those NSAPIs for which 
there are radio resources allocated in the target cell. All other NSAPIs shall be handled following the legacy 
procedures during routing area change, thus the MS shall not resume the uplink user data transfer until the 
routing area update procedure is completed. 
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8. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the target BSS 
sends a PS Handover Complete (Local TLLI, Handover Complete Status) message to inform the PFM entity 
in the SGSN that the MS has arrived in the target cell. The source BSS initiates the release of the radio 
resources in the source cell. After the reception of the PS Handover Complete message the new SGSN shall 
be prepared to receive data from the target BSS. 

9. The new SGSN sends an Update PDP Context Request (New SGSN Address, TEID, QoS Negotiated) 
message to the GGSN concerned. The GGSN updates the PDP context fields and returns an Update PDP 
Context Response (TEID) message. From now on the GGSN sends new incoming downlink IP packets only 
to the new SGSN. Each uplink N-PDU received by the new SGSN prior to updating the PDP Context for the 
associated PEC by the Update PDP Context Request message is discarded. Once the new SGSN has updated 
the PDP Context for any given PEC, it starts sending all associated uplink N-PDUs it receives directly to the 
GGSN. 

10. The new SGSN sends a Forward Relocation Complete (IMSI, Handover Complete Status) message to the old 
SGSN. The old SGSN responds with a Forward Relocation Complete Acknowledge message. Upon the 
reception of the Forward Relocation Complete message the old SGSN starts a packet forwarding timer. The 
old SGSN stops forwarding of data to the new SGSN after the packet forwarding timer expires. 

11. The old SGSN deletes to BSS packet flow context towards the old cell. 

12. The MS sends a Routing Area Update Request (Old RAI, Old P-TMSI signature) message to the new SGSN 
informing it that the source cell belongs to a new routing area. The MS shall send this message immediately 
after message 6. The new SGSN knows that a handover has been performed for this MS and can therefore 
exclude the SGSN context procedures that normally are used within the RA Update procedure. 

13. At this point the new SGSN may optionally invoke MS authentication (security function). The security 
function can be deferred and performed at any later time as well. 

14. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN 
Address, IMSI) message to the HLR. 

15. The HLR sends Cancel Location (IMSI, Cancellation Type) message to the old SGSN with Cancellation Type 
set to Update Procedure. The old SGSN acknowledges with a Cancel Location Acknowledge (IMSI) 
message. This message allows the old SGSN to know when to release the inter-SGSN tunnel. 

16. The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new SGSN. The new SGSN 
validates the MS presence in the (new) RA. If all checks are successful then the new SGSN constructs an MM 
context for the MS and returns an Insert Subscriber Data Acknowledge (IMSI) message to the HLR. This 
message allows the new SGSN to know when to release the inter-SGSN tunnel. 

17. The HLR acknowledges the Update Location by sending an Update Location Acknowledge (IMSI) message 
to the new SGSN. 

18. The new SGSN validates the MS presence in the new RA. If the MS is allowed to be attached in this RA, the 
SGSN updates the MM context for and sends a Routing Area Update Accept (P-TMSI, TMSI, P-TMSI 
signature. Receive N-PDU number) message to the MS. The Receive N-PDU Number contains the 
acknowledgements for each acknowledged-mode NSAPI used by the SGSN, thereby confirming all mobile- 
originated N-PDUs successfully transferred before the start of the PS handover procedure. 

19. The MS confirms the re-allocation of the new P-TMSI by responding the SGSN with a Routing Area Update 
Complete (Receive N-PDU number) message. The MS derives a new local TLLI from the new P-TMSI using 
current MM procedures. The Receive N-PDU Number contains the acknowledgements for each 
acknowledged-mode NSAPI used by the MS, thereby confirming all mobile -terminated N-PDUs successfully 
transferred before the start of the handover procedure. If Receive N-PDU Number confirms reception of 
N-PDUs that were forwarded from the old SGSN, these N-PDUs shall be discarded by the new SGSN. 
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5.2 Inter-RAT/mode handover (GERAN A/Gb ^ UTRAN, 
GERAN lu) 



5.2.1 



Intra SGSN 



5.2.1.1 



Intra-SGSN GERAN A/Gb to UTRAN/GERAN lu HO; Preparation phase 



MS 



Source 
BSS 



Target 
RNC/BSS 



1. Handover decision 



2. PS Hardover Required 



3G/2G 
SGSN 



3. Relocation Request 



4. Relocation Request / cknowledge 



Figure 11: PS Handover Preparation Phase; Inter-RAT/mode, 
Intra-SGSN case (GERAN A/Gb ^ UTRAN, GERAN lu) 

1. The source BSS decides to initiate a PS handover. At this point both upHnk and downhnk user data is transmitted 
via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between the source BSS and 
3G/2G SGSN, GTP tunnel(s) between the 3G/2G SGSN and GGSN. 

2. The source BSS sends a PS Handover Required (TLLI, Source Cell Identifier, Target ID, Source RNC to 
Target RNC Transparent Container) message to the SGSN. 

3. The 3G/2G SGSN determines from the Target ID the type of handover, i.e. intra-SGSN, inter-SGSN or 
inter-RAT/mode handover. In case of Inter-RAT/Intra-SGSN PS handover, the 3G/2G SGSN constructs a 
Relocation Request (Permanent NAS Identity, Cause, CN Domain Indicator, Integrity protection information 
(i.e. IK and allowed Integrity Protection algorithms. Encryption information (i.e. CK and allowed Ciphering 
algorithms), RABs To Be Set Up List, Source RNC to Target RNC Transparent Container, lu Signalling 
connection identifier. Global CN-ID, SNA Access Information, UESBI-Iu) message to the target RNC/BSS. 

For each RAB requested to be established, the RABs To Be Set Up List shall contain information such as RAB 
ID, RAB parameters. Transport Layer Address, and lu Transport Association. The 3G/2G SGSN shall not 
request resources for PFCs associated with PDP contexts with a maximum bit rate for uplink and downlink of 
kbit/s. The RAB ID information element contains the NSAPI value, and the RAB parameters information 
element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the lu 
Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. 

Ciphering and integrity protection keys are sent to the target RNC/BSS to allow data transfer to continue in the 
new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. 
Information that is required to be sent to the MS (either in the PS Handover Command message or after the 
handover completion message) from RRC in the target RNC/BSS shall be included in the RRC message sent 
from the target RNC/BSS to the MS via the transparent container. 

In the target RNC/BSS radio and lu user plane resources are reserved for the accepted RABs. 

4. The target RNC/BSS sends the Relocation Request Acknowledge (Target RNC to Source RNC Transparent 
Container, RABs setup list, RABs failed to setup list) message to the 3G/2G SGSN for the accepted PFCs. Upon 
sending the Relocation Request Acknowledge message the target RNC/BSS shall be prepared to receive 
downlink LLC PDUs from the 3G/2G SGSN for the accepted PFCs. 

Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC/BSS Address for user 
data, and the lu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user 
data. 
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NOTE: The information to be included in the containers differs for UTRAN and GERAN lu mode. For UTRAN, 
the information included in the container is related to RAB setup and other IE similar to those in the 
Handover to UTRAN message defined in 3GPP TS 25.331 [17]. For GERAN lu mode the Radio 
Bearer Reconfiguration message defined in 3GPP TS 44. 118 [16] is the RRC message to be included. 

When the 3G/2G SGSN receives the Relocation Request Acknowledge message and it decides to proceed with 
the handover, the preparation phase is finished and the execution phase will follow. 



5.2.1.2 



Intra-SGSN GERAN A/Gb to UTRAN/GERAN lu HO; Execution phase 



MS 



Source 
BSS 



5. PS Handover Con 



6. UTRAN Handover 
GERAN lu Access 



Sending of upl 



Target 
RNC/BSS 



1 . IP packets 1 1 source BSS 



3. PS Hardover Command 



mand 

Execution or 
Bursts, Physical 



nfo 



7. Relocation Detect 



. Handover to UTRA|J Complete or 
Radio Bearer Reco ifiguration Comp ete 



nk data possib 



3G/2G 
SGSN 



_2 -Send rel_a^ed.!^-J'DUs over 
the"allocated liABs 



4. Forward SRNS C sntext 



(GERAN lu) 
9. Relocation Complelte 



1. IP packets to targe 



10. BSS Packet Flow procedure^ 



1 1 . R; tU request 



12. RkU accept 



13. RAJ Complete 



GGSN 



RNC/BSS 



Figure 12: PS Handover Execution Phase; Inter-RAT/mode, 
Intra-SGSN case (GERAN A/Gb ^ UTRAN, GERAN lu) 

1. The 3G/2G SGSN continues to receive IP packets from the GGSN (via GTP) and forwards the associated PDU 
payload to the MS via the source BSS. 

2. When receiving the Relocation Request Acknowledge message the 3G/2G SGSN may, based on QoS, start 
downlink N-PDU relay and duplication to the target RNC/BSS if a Tunnel Endpoint is available as follows: 

• For each PDP context which uses LLC ABM, all new downlink N-PDUs received after completion of the PS 
handover preparation phase are duplicated and relayed to the target RNC/BSS and the transmitted but not yet 
acknowledged downlink N-PDUs are duplicated and routed together with their N-PDU number to the target 
RNC/BSS. All such N-PDUs are encapsulated in a GTP-PDU when transmitted to the target RNC/BSS. 
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• For PDP context, which uses LLC ADM, all new downlink N-PDUs received after completion of the PS 
handover preparation phase are relayed to the target RNC. All such N-PDUs are encapsulated in a GTP-PDU 
when transmitted to the target RNC/BSS. 

• If the 3G/2G SGSN forwards downlink packets to the target RNC/BSS, the target RNC/BSS may start blind 
transmission of downlink user data towards the MS over the allocated radio channels. 

• In the network, N-PDUs are forwarded from the SGSN to the target RNC/BSS and the PDCP sequence 
number is derived from the N-PDU sequence number (sent as part of the PDP context) with the 8 most 
significant bit I's added. It is FFS where this sequence number translation will be done. 

3. The 3G/2G SGSN continues the PS Handover by sending a PS Handover Command (TLLI, Target RNC ID, 
PFCs To Be Set Up List, Target RNC to Source RNC Transparent Container) message to the source BSS. 

Before sending the PS Handover Command message, the 3G/2G SGSN, based on QoS, suspends downlink 
data transfer: 

• for PDP contexts, which require delivery order to be preserved; and 

• for PDP contexts, which are sensitive to packet loss. 

Before sending the PS Handover Command message to the MS the source BSS, based on QoS, tries to empty 
the downlink BSS buffer: 

• for BSS PFCs, which require delivery order to be preserved; and 

• for BSS PFCs, which are sensitive to packet loss. 

The source BSS receiving the PS Handover Command message stops the uplink traffic, based on QoS, for 
flows, which require delivery order to be preserved. 

4. The 3G/2G SGSN shall send the Forward SRNS Context (Send N-PDU number. Receive N-PDU number, 
DL GTP-U number, UL GTP-U number) message to the target RNC/BSS if there is at least one PDP context 
which either requires "delivery order" to be preserved or which uses LLC ABM. The forward SRNS message 
contains the sequence numbers of the GTP-PDU next to transmitted in the uplink and downlink direction and 
the next N-PDU number that would have been used to send and receive data from the MS. 

The N-PDU numbers are only sent by the 3G/2G SGSN for PDP contexts, which uses LLC ABM. The GTP-U 
numbers are only sent by the 3G/2G SGSN for PDP context(s) requiring delivery order (QoS profile) to be 
preserved. If delivery order is to be preserved (QoS) profile), consecutive GTP-PDU sequence numbering shall 
be maintained through the lifetime of the PDP context(s). 

Therefore, during the entire PS Handover procedure for the PDP context(s) using delivery order required (QoS 
profile), the responsible GTP-U entities (3G/2G SGSN, target RNC/BSS and GGSN) shall assign consecutive 
GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink and downlink, 
respectively. 

The target RNC/BSS proceed as follows: 

• For RABs which require lossless PDCP in the target RNC/BSS, the target RNC/BSS stores the N-PDUs in 
the PDCP queue and converts the Send N-PDU number (if present) into a PDCP sequence number by adding 
eight most significant bits "1". 

• For RABs not requiring lossless PDCP the target RNC/BSS may, according the QoS profile of the PDP 
context, store the received data until it receives confirmation of MS presence in the target cell. 

The further target RNC/BSS behaviour is as specified in 3GPP TS 23.060 [19] (Combined Hard Handover 
and SRNS Relocation). 
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5. The source BSS sends the PS Handover Command message containing the Handover to UTRAN 

Command message (as it is specified in 3GPP TS 25.331 [17]) or Radio Bearer Reconfiguration message 
(as it is specified in 3GPP TS 44. 118 [16]) to the MS by interrupting the transmission of LLC PDUs on any of 
the downlink TBFs. Following the transmission of this signalling message the source BSS immediately 
resumes LLC PDU transmission until it either has no more LLC PDUs to send or the PFC is released. MS 
management of uplink N-PDUs following the reception of the PS Handover Command message is as 
follows: 

• All N-PDUs associated with a PFC receiving handover treatment that have not yet been fully transmitted 
might be buffered depending on the QoS class. 



• 



Subsequent uplink N-PDUs that become available for transmission following the reception of the PS 
Handover Command message might also be buffered depending on the QoS class. 

• For real time services uplink N-PDUs may be discarded by the MS during the link interruption. 

NOTE: Any buffering should be performed before the data is passed to SNDCP in order to avoid header 

compression on N-PDUs such that data delivery in the target cell may begin from the correct point in the 
sequence. 

6. MS is in the target cell and performs access to UTRAN as defined in 3GPP TS 25.331 [17] and to GERAN lu 
mode as defined in 3GPP TS 44.118 [16]. 

7. The target RNC/BSS sends a Relocation Detect message to the 3G/2G SGSN to indicate that the MS is in the 
target cell. The message shall be sent when the relocation execution trigger is received. For SRNS relocation 
type "UE Involved", the relocation execution trigger may be received from the Uu interface; i.e. when the 
target RNC detects the MS on the lower layers. When the Relocation Detect message is sent, the target RNC 
shall start source RNC operation. 

8. In UTRAN, the MS sends Handover to UTRAN Complete {Message Type, UE Information elements (Start 
List, CN Domain Identity, Start), RB Information Elements (Count-C Activation Time)} message to the target 
RNC (see 3GPP TS 25.331 [17]). 

In GERAN lu, the MS sends Radio Bearer Reconfiguration Complete {RRC Transaction Identifier, 
Integrity Check Info, Uplink Integrity Protection Activation Info, COUNT-C Activation Time, Radio Bearer 
Uplink Ciphering Activation Time Info, Mobile Observed Time Difference, Uplink Counter Synchronisation 
Info struct, START List, CN Domain Identity, START, RB with PDCP Information List, RB with PDCP 
Information} message to target BSS. 

9. When the new source RNC-ID + S-RNTl are successfully exchanged with the MS, the target RNC/BSS shall 
send the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure 
is to indicate by the target RNC/BSS the completion of the relocation of the source BSS to the CN. After the 
reception of the Relocation Complete message the 3G/2G SGSN shall be prepared to receive data from the 
target RNC/BSS. 

10. The 3G/2G SGSN shall initiate PFC Management procedures towards the source cell in order to trigger the 
release of resources in the source cell. 

11. The MS sends a Routing Area Update Request (Old RAI, Old P-TMSl signature. Update Type) message to 
the 3G/2G SGSN informing it that the source cell belongs to a new routing area. The MS shall send this 
message immediately after message 8. The 3G/2G SGSN knows that a handover has been performed for this 
MS and can therefore exclude the SGSN context procedures which normally are used within the RA Update 
procedure. 

12. The 3G/2G SGSN validates the MS presence in the new RA. If the MS is allowed to be attached in this RA, 
the 3G/2G SGSN updates the MM context for and sends a Routing Area Update Accept message to the MS. 

13. The MS may respond to the SGSN with a Routing Area Update Complete message. 
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5.2.2 Inter SGSN 
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Figure 13: PS Handover Preparation Phiase; Inter-RAT/mode, 
Inter-SGSN case (GERAN A/Gb -> UTRAN, GERAN lu) 

1. The source BSS decides to initiate a PS handover. At this point both upHnk and downhnk user data is transmitted 
via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between source BSS and old 
SGSN, GTP tunnel(s) between old SGSN and GGSN. 

2. The source BSS sends a PS Handover Required (TLLI, Source Cell Identifier, Target ID, Source RNC to 
Target RNC Transparent Container) message to the old SGSN. 

3. The old SGSN determines from the Target ID the type of handover, i.e. intra-SGSN, inter-SGSN or inter- 
RAT/mode handover. In case of inter-SGSN inter-RAT/mode PS handover the old SGSN initiates the relocation 
resource allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification, MM 
Context, PDP Context, PDP Context Prioritisation, Tunnel Endpoint Identifier Control Plane, SGSN Address for 
Control plane. Source RNC to Target RNC Transparent Container, UTRAN Transparent Container, RANAP 
Cause) message to the new SGSN. 

The old SGSN sends all active PDP Contexts to the new SGSN indicating the PFIs and the XID parameters 
related to those PDP Contexts. 

As part of the MM context the following security related information is included: 



Kc 

CKSN 

Used Cipher 

MS Network Capability 



Ciphering key for GPRS. 
Ciphering Key Sequence Number of Kc. 
Selected ciphering algorithm for GPRS (GEA). 
Includes ciphering algorithms supported by the MS. 



The values for CK (UMTS Ciphering Key) and IK (UMTS Integrity protection Key) are calculated from the Kc and the 
KSI (Key Set Identifier) takes the same value as CKSN. 

NOTE 1 : For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, 
the old SGSN may - if it provides Intra Domain Connection of RAN Nodes to Multiple CN Nodes -have 
multiple new SGSNs for each handover target in a pool area, in which case the old SGSN will select one 
of them to become the new SGSN, as specified in 3GPP TS 23.236 [22]. 



£75/ 



3GPPTS 43.129 version 6.1.0 Release 6 35 ETSI TS 143 129 V6.1.0 (2005-01) 

Upon receipt of the message, the new SGSN establishes all MM and PDP contexts and initiates the RAB setup 
procedures for all PDP contexts received. 

1. In case of Inter-RAT/Inter-SGSN PS handover, the new SGSN constructs a Relocation Request (Permanent 
NAS Identity, Cause, CN Domain Indicator, Integrity protection information (i.e. IK and allowed Integrity 
Protection algorithms. Encryption information (i.e. CK and allowed Ciphering algorithms), RABs to be setup 
list. Source RNC to Target RNC Transparent Container, lu Signalling connection identifier. Global CN-ID, SNA 
Access Information, UESBI-Iu) message to the target RNC/BSS. 

For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB 
parameters. Transport Layer Address, and lu Transport Association. The new SGSN shall not request resources 
for PFCs associated with PDP contexts with a maximum bit rate for uplink and downlink of kbit/s. The RAB 
ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS 
profile. The Transport Layer Address is the SGSN Address for user data, and the lu Transport Association 
corresponds to the uplink Tunnel Endpoint Identifier Data. 

Ciphering and integrity protection keys are sent to the target RNC/BSS to allow data transfer to continue in the 
new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. 
Information that is required to be sent to the MS (either in the PS Handover Command message or after the 
handover completion message) from RRC in the target RNC/BSS shall be included in the RRC message sent 
from the target RNC/BSS to the MS via the transparent container. 

In the target RNC/BSS radio and lu user plane resources are reserved for the accepted RABs. 

2. The target RNC/BSS sends the Relocation Request Acknowledge (Target RNC to Source RNC Transparent 
Container, RABs setup list, RABS failed to setup list) message to the new SGSN. Upon sending the Relocation 
Request Acknowledge message the target RNC/BSS shall be prepared to receive downlink LLC PDUs from the 
new SGSN for the accepted PFCs. 

Each RAB to be setup is defined by a Transport Layer Address, which is the target RNC/BSS Address for user data, and 
the lu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data. 

NOTE 2: The information to be included in the containers differs for UTRAN and GERAN lu mode. For UTRAN, 
the information included in the container is related to RAB setup and other IE similar to those in the 
Handover to UTRAN message defined in 3GPP TS 25.331 [17]. For GERAN lu mode the Radio 
Bearer Reconfiguration message defined in 3GPP TS 44.1 18 [16] is the RRC message to be included. 

3. When resources for the transmission of user data between target RNC/BSS and new SGSN have been allocated 
and the new SGSN is ready for the PS handover, the Forward Relocation Response (Cause, Tunnel Endpoint 
Identifier Control Plane, RANAP cause, SGSN Address for control plane. Target RNC to Source RNC 
Transparent Container in the UTRAN Transparent Container, RAB setup information. Additional RAB setup 
information) message is sent from the new SGSN to the old SGSN. RAN Transparent Container and RANAP 
Cause contain information from the target RNC/BSS to be forwarded to the source BSS. 

The RAB Setup Information Element, one information for each PDP context, contains the RNC tunnel endpoint 
and the RNC IP address for data forwarding from the old SGSN to the target RNC. 

When the old SGSN receives the Forward Relocation Response message and it decides to proceed with the 
handover, the preparation phase is finished and the execution phase will follow. 
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5.2.2.2 Inter-SGSN GERAN A/Gb to UTRAN/GERAN lu HO; Execution phase 
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Figure 14: PS Handover Execution Phase; Inter-RAT/mode, 
Inter-SGSN case (GERAN A/Gb ^ UTRAN/GERAN lu) 

1 . The old SGSN continues to receive IP packets from the GGSN (via GTP) and forwards the associated PDU 
payload to the MS via the source BSS. 
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2. When receiving the Relocation Request Acknowledge message the old SGSN may, based on QoS, start 
downhnk N-PDU relay and duplication to the target RNC/BSS if a Tunnel Endpoint is available as follows: 

• For each PDP context which uses LLC ABM in the old SGSN, all new downlink N-PDUs received after 
completion of the PS handover preparation phase are duplicated and relayed to the target RNC/BSS and the 
transmitted but not yet acknowledged downlink N-PDUs are duplicated and routed together with their 
N-PDU number to the target RNC/BSS. All such N-PDUs are encapsulated in a GTP-PDU when transmitted 
to the target RNC/BSS. 

• For PDP context, which uses LLC ADM in the old SGSN all new downlink N-PDUs received after 
completion of the PS handover preparation phase are relayed to the target RNC/BSS. All such N-PDUs are 
encapsulated in a GTP-PDU when transmitted to the target RNC/BSS. 

If the old SGSN forwards downlink packets to the target RNC/BSS, the target RNC/BSS may start blind 
transmission of downlink user data towards the MS over the allocated radio channels. 

In the network, N-PDUs are forwarded from the old SGSN to the target RNC/BSS and the PDCP sequence 
number is derived from the N-PDU sequence number (sent as part of the PDP context) with 8 most significant 
bit I's added. It is FFS where this sequence number translation will be done. 

NOTE 1 : The order of steps, starting from step 2 onwards, does not necessarily reflect the order of events. For 
instance the old SGSN may start data forwarding (step 2), send the PS Handover Command message 
(step 4) and send the Forward SRNS context message (step 4a) almost simultaneously. 

3. Void 

4. The old SGSN continues the PS Handover by sending a PS Handover Command (Old TLLI, Target RNC ID, 
PFCs To Be Set Up List, Target RNC to Source RNC Transparent Container) message to the source BSS. 

Before sending the PS Handover Command message, the old SGSN based on QoS, suspends downlink data 
transfer: 

• for PDP contexts, which require delivery order to be preserved; and 

• for PDP contexts, which are sensitive to packet loss. 

Before sending the PS Handover Command message to the MS the source BSS based on QoS, tries to empty 
the downlink BSS buffer: 

• for BSS PFCs, which require delivery order to be preserved; and 

• for BSS PFCs, which are sensitive to packet loss. 

The source BSS receiving the PS Handover Command message stops the uplink traffic, based on QoS, for 
flows, which require delivery order to be preserved. 

4a. The old SGSN shall send the Forward SRNS Context message (Send N-PDU number. Receive N-PDU 

number, DL GTP-U number, UL GTP-U number) to the new SGSN if there is at least one PDP context which 
either requires "delivery order" to be preserved or which uses LLC ABM. The Forward SRNS Context 
message is then acknowledged by the Forward SRNS Context Acknowledge message. The forward SRNS 
message contains the sequence numbers of the GTP-PDU next to transmitted in the uplink and downlink 
direction and the next N-PDU number that would have been used to send and receive data from the MS. 

The N-PDU numbers are only sent by the old SGSN for PDP contexts, which uses LLC ABM. 
The GTP-U numbers are only sent by the old SGSN for PDP context(s) requiring delivery order (QoS profile) 
to be preserved. If delivery order is to be preserved (QoS) profile), consecutive GTP-PDU sequence numbering 
shall be maintained through the lifetime of the PDP context(s). 

Therefore, during the entire PS Handover procedure for the PDP context(s) using delivery order required (QoS 
profile), the responsible GTP-U entities (old SGSN, target RNC and GGSN) shall assign consecutive 
GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink and downlink, 
respectively. 
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The target RNC proceed as follows: 

• For RABs which require lossless PDCP in the target RNC, the target RNC stores the N-PDUs in the PDCP 
queue and converts the Send N-PDU number (if present) into a PDCP sequence number by adding eight most 
significant bits "1". 



• 



For RABs not requiring lossless PDCP the target RNC may, according the QoS profile of the PDP context, 
store the received data until it receives confirmation of MS presence in the target cell. 

The further target RNC/BSS behaviour is as specified in 3GPP TS 23.060 [19] (Combined Hard Handover 
and SRNS Relocation). 

5. The source BSS sends the PS Handover Command message containing the Handover to UTRAN 
Command message (as specified in 3GPP TS 25.331 [17]) or Radio Bearer Reconfiguration message (as 
specified in 3GPP TS 44. 118 [16]) to the MS by interrupting the transmission of LLC PDUs on any of the 
downlink TBFs. Following the transmission of this signalling message the source BSS immediately resumes 
LLC PDU transmission until it either has no more LLC PDUs to send or the PFC is released. MS management 
of uplink N-PDUs following the reception of the PS Handover Command message is as follows: 

• All N-PDUs associated with a PFC receiving handover treatment that have not yet been fully transmitted 
might be buffered depending on the QoS class. 

• Subsequent uplink N-PDUs that become available for transmission following the reception of the PS 
Handover Command message might also be buffered depending on the QoS class. 

• For real time services uplink N-PDUs may be discarded by the MS during the link interruption. 

NOTE 2: Any buffering should be performed before the data is passed to SNDCP in order to avoid header 

compression on N-PDUs such that data delivery in the target cell may begin from the correct point in the 
sequence. 

6. MS is in the target cell and performs access to UTRAN as defined in 3GPP TS 25.331 [17] and to GERAN lu 
mode as defined in 3GPP TS 44.1 18 [16]. 

7. Target RNC/BSS sends a Relocation Detect message to the new SGSN to indicate that the MS is in the target 
cell. The message shall be sent when the relocation execution trigger is received. For SRNS relocation type 
"UE Involved", the relocation execution trigger may be received from the Uu interface; i.e. when the target 
RNC detects the MS on the lower layers. When the Relocation Detect message is sent, the target RNC shall 
start source RNC operation. 

8. In UTRAN, MS sends Handover to UTRAN Complete {Message Type, UE Information elements (Start List, 
CN Domain Identity, Start), RB Information Elements (Count-C Activation Time)} message to the target RNC 
(see 3GPPTS 25.331 [17]). 

In GERAN lu, MS sends Radio Bearer Reconfiguration Complete {RRC Transaction Identifier, Integrity 
Check Info, Uplink Integrity Protection Activation Info, COUNT-C Activation Time, Radio Bearer Uplink 
Ciphering Activation Time Info, Mobile Observed Time Difference, Uplink Counter Synchronisation Info 
struct, START List, CN Domain Identity, START, RB with PDCP Information List, RB with PDCP 
Information} message to target BSS. 

9. When the new source RNC-ID + S-RNTI are successfully exchanged with the MS, the target RNC/BSS shall 
send the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure 
is to indicate by the target RNC/BSS the completion of the relocation of the source BSS to the CN. After the 
reception of the Relocation Complete message the 3G/2G SGSN shall be prepared to receive data from the 
target RNC/BSS. 

10. The reception of the Relocation Complete message in the new SGSN triggers the sending of an Update PDP 
Context Request (new SGSN Address, TEID, QoS Negotiated) message to the GGSN concerned. The GGSN 
updates the PDP context fields and returns an Update PDP Context Response (TEID) message. From now on 
the GGSN sends new incoming downlink IP packets only to the new SGSN. Each uplink N-PDU received by 
the new SGSN prior to updating the PDP Context for the associated RAB by the Update PDP Context 
Request message is discarded. Once the new SGSN has updated the PDP Context for any given RAB, it starts 
sending all associated uplink N-PDUs it receives directly to the GGSN. 
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11. For inter-SGSN PS handover, the new SGSN sends a Forward Relocation Complete message to the old 
SGSN to indicate the success of the handover procedure. The old SGSN acknowledges this with a Forward 
Relocation Complete Acknowledge message. Upon the reception of the Forward Relocation Complete 
message the old SGSN starts a packet forwarding timer. The old SGSN stops forwarding of data to the new 
SGSN after the packet forwarding timer expires. 

12. The old SGSN shall initiate PFC Management procedures towards the source cell in order to trigger the release 
of resources in the source cell. 

13. The MS sends a Routing Area Update Request (Old RAI, Old P-TMSI signature, Update Type) message to 
the new SGSN informing it that the source cell belongs to a new routing area. The MS shall send this message 
immediately after message 7. The new SGSN knows that a handover has been performed for this MS and can 
therefore exclude the SGSN context procedures which normally are used within the RA Update procedure. 

14. At this point the new SGSN may optionally invoke MS authentication (security function). The security 
function can be deferred and performed at any later time as well. 

15. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN 
Address, IMSI) message to the HLR. 

16. The HLR sends Cancel Location (IMSI, Cancellation Type) message to the old SGSN with Cancellation Type 
set to Update Procedure. 

17. The old SGSN acknowledges with a Cancel Location Acknowledge (IMSI) message. This message allows the 
old SGSN to know when to release the inter-SGSN tunnel. 

18. The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) message to the new SGSN. The new 
SGSN validates the MS presence in the (new) RA. 

19. If all checks are successful then the new SGSN constructs an MM context for the MS and returns an Insert 
Subscriber Data Acknowledge (IMSI) message to the HLR. This message allows the new SGSN to know 
when to release the inter-SGSN tunnel. 

20. The HLR acknowledges the Update Location by sending an Update Location Acknowledge (IMSI) message 
to the new SGSN. 

21. The new SGSN validates the MS presence in the new RA. If the MS is allowed to be attached in this RA, the 
SGSN updates the MM context for and sends a Routing Area Update Accept message to the MS. 

22. The MS may respond to the SGSN with a Routing Area Update Complete message. 
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5.3 Inter-RAT/mode Handover (UTRAN/GERAN lu ^ GERAN 
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Figure 15: PS Handover Preparation Phase; Inter-RAT/mode, 
Intra-SGSN case (UTRAN/GERAN lu ^ GERAN A/Gb) 

1. Based on measurement results and knowledge of the RAN topology, the source RNC/BSS decides to initiate an 
inter RAT/mode PS handover towards the GERAN A/Gb. At this point both uplink and downlink user data flows 
via the tunnel(s): Radio Bearer between the MS and the source RNC/BSS; GTP-U tunnel(s) between the source 
RNC/BSS and the 3G/2G SGSN; GTP-U tunnel(s) between the 3G/2G SGSN and the GGSN. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this paper. 

2. The source RNC/BSS sends a Relocation Required (Relocation Type, Cause, Source ID, Target ID, MS 
Classmark 2, MS Classmark 3, Source BSS To Target BSS Transparent Container [RN part]) message to the 
3G/2G SGSN. The source RNC/BSS shall set Relocation Type to "UE Involved in relocation of SRNS". 

Target ID contains the ID of the target cell BSS. 

NOTE 2: The Target ID contains the CGI if GERAN is the target cell. Considering that CGI contains only LAI and 
CI, it will be problematic for the SGSN to determine the target cell in PS domain without the RAI. The 
same is valid in case of UTRAN-GERAN PS handover. 

3. The 3G/2G SGSN determines from the Target ID the type of handover, i.e. intra-SGSN, inter-SGSN or 
inter-RAT/mode handover. In case of Inter-RAT/Intra-SGSN PS handover, the 3G/2G SGSN sends a PS 
Handover Request (TLLI, IMSI, Target Cell Identifier, Source BSS to Target BSS Transparent Container 
[RN part], PFC(s) To Be Set Up List, XiD Command) message to the target BSS. The 3G/2G SGSN shall not 
request resources for PFCs associated with PDP contexts with a maximum bit rate for uplink and downlink of 
kbit/s. 
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4. Based upon the ABQP for each PFC the target ESS makes a decision about which PFCs to assign radio 
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. 
Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS 
allocates TBFs for each PFC that can be accommodated by the target BSS. 

NOTE 3: For each N-SAPI associated to a PFC in the PFCs To Be Set Up List, the 3G/2G SGSN shall provide an 
XID Command. 

After allocating radio resources the target BSS shall prepare the Target BSS to Source BSS Transparent 
Container for the set up BSS PFCs. 

5. If the target BSS is not able to allocate resources for one or more BSS PFCs it shall send PS Handover BSS 
PFC Status Report (Set Up PFCs, Failed to Set Up PFCs) message to the 3G/2G SGSN. 

6. Upon receiving the PS Handover BSS PFC Status Report message the 3G/2G SGSN sends the XID Command 
for each of the set up PFCs to the target BSS in the PS Handover BSS PFC Status Report Acknowledge (XID 

Command for the set up BSS PFC) message. 

7. After receiving all the necessary information for the accepted PFCs the target BSS shall prepare the Target BSS 
to Source BSS Transparent Container including the XID Commands only for the set up BSS PFCs. 

8. The target BSS shall send the PS Handover Request Acknowledge message (TLLI, Cause, PFCs Setup, failed 
PFCs, Target BSS to Source BSS Transparent Container [RN part, CN part]) message to the 3G/2G SGSN for 
the accepted PFCs. Upon sending the PS Handover Request Acknowledge message the target BSS shall be 
prepared to receive downlink LLC PDUs from the 3G/2G SGSN for the accepted PFCs. 

Any PDP contexts for which a PFC was not established will be released. 

When the 3G/2G SGSN receives the PS Handover Request Acknowledge message and it decides to proceed 
with the handover, the preparation phase is finished and the execution phase will follow. 
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Figure 16: PS Handover Execution Phase; Inter-RAT/mode, 
Intra-SGSN case (UTRAN/GERAN lu ^ GERAN A/Gb) 

1. The 3G/2G SGSN continues to receive IP packets from the GGSN (via GTP) and forwards the associated PDU 
payload to the MS via the source RNC/BSS. 

2. The 3G/2G SGSN continues the PS handover by sending a Relocation Command (Target RNC to Source 
RNC Transparent Container [RN part, CN part], RABS to be Released List, RABs Subject to Data Forwarding 
List) message to the source RNC/BSS. "RABs to be released list" will be the Hst of all NSAPIs (RAB Ids) for 
which a PFC was not established "RABs Subject to Data forwarding list" will be the list of all NSAPIs (RAB 
Ids) for which a PFC was established. 

3. When receiving the Relocation Command message the source RNC may, based on QoS, begin the forwarding 
of data for the RABs subject to data forwarding to the 3G/2G SGSN according to the definition in 
3GPPTS 23.060 [19]. 

The 3G/2G SGSN may, based on QoS, proceed with the packet handling as follows: 

• For PDP contexts, which use LLC ABM the 3G/2G SGSN converts the PDCP sequence number into a Send 
N-PDU number (this is done by stripping off the 8 most significant bits of the PDCP sequence number) and 
stores the N-PDU associated with each Send N-PDU number into the SNDCP queue. Data transfer prior the 
exchange of N-PDU SNs between MS and 3G/2G SGSN is not possible. 

• For PDP contexts which use LLC ADM the 3G/2G SGSN either: 
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a. forwards the received downlink N-PDUs to the target BSS; 

b. stores the received data into the SNDCP queue for e.g. the PDU Hfetime; 

c. discards the received data until e.g. reception of the PS Handover Complete message. 

If the 3G/2G SGSN forwards packets to the target BSS, the target BSS may start a blind transmission of 
downlink user data towards the MS over the allocated radio channels. 

4. The RNC/BSS sends the Handover from UTRAN Command message (UTRAN) or the Handover from 

GERAN lu Command message to the MS. Before sending the message the uplink and downlink data transfer 
shall be suspended in the source RNC for the RABs that require delivery order. 

5. The source RNC/BSS continues the handover by sending a Forward SRNS Context (RAB contexts) message 
to the 3G/2G SGSN. 

The source RNC/BSS behavior is as specified in 3GPP TS TS 23.060 [19] (Combined Hard Handover and 
SRNS Relocation). 

6. The MS executes the handover according to the parameters provided in the message delivered in step 5. The 
procedure is the same as in step 6 in clause 5.1.4.2. 

7. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 6, 
the MS immediately sends one XID Response (e.g. lOV) message to the 3G/2G SGSN for each XID 
Command message received in the source cell, thereby informing the SGSN about the negotiated security 
parameters. For LLC ABM, the XID Response message is followed by a SABM-UA exchange procedure as 
defined in TS 44.064. To make the handover interruption short the MS sends this message immediately after 
receiving the Physical Information message or, in the synchronised network case, immediately after the 
sending of the PS Handover Access message. 

8. Upon reception of the first correct RLC/MAC block (sent in normal burst format) the target BSS sends a PS 
Handover Complete (TLLI, Handover Complete Status) message to inform the PFM entity in the 3G/2G 
SGSN that the MS has arrived in the target cell. The source RNC/BSS initiates the release of the radio 
resources in the source cell. After the reception of the PS Handover Complete message the 3G/2G SGSN 
shall be prepared to receive data from the target BSS. 

9. The 3G/2G SGSN sends an lu Release Command message to the source RNC/BSS commanding the source 
RNC/BSS to release all resources related to the lu connection. When the RNC/BSS data forwarding timer has 
expired the source RNC/BSS responds with an lu Release Complete (RAB Data Volume report list, RABs 
released list) message. 

10. The MS sends a Routing Area Update Request (Old P-TMSI, Old RAI, Old P-TMSI signature. Update Type) 
message to the 3G/2G SGSN informing it that the source cell belongs to a new routing area. The MS shall send 
this message immediately after message 7, see 3GPP TS 23.060 [19]. 

The 3G/2G SGSN knows that a handover has been performed for this MS and can therefore exclude the SGSN 
context procedures which normally are used within the RA Update procedure. 

1 1 . The 3G/2G SGSN validates the MS presence in the new RA. If the MS is allowed to be attached in this RA, 
the 3G/2G SGSN updates the MM context for and sends a Routing Area Update Accept (P-TMSI, TMSI, 
P-TMSI signature. Receive N-PDU number) message to the MS. The Receive N-PDU Number contains the 
acknowledgements for each acknowledged-mode NSAPI used by the 3G/2G SGSN, thereby confirming all 
mobile originated N-PDUs successfully transferred before the start of the PS handover procedure. 
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12. The MS confirms the re-allocation of the new P-TMSl by responding the 3G/2G SGSN with a Routing Area 
Update Complete (Receive N-PDU number). The MS derives the TLLl from the new P-TMSl using the 
current MM procedures. The Receive N-PDU Number contains the acknowledgements for each acknowledged 
mode NSAPI used by the MS, thereby confirming all mobile terminated N-PDUs successfully transferred 
before the start of the handover procedure. If Receive N-PDU Number confirms reception of N-PDUs that 
were forwarded from the 3G/2G SGSN, these N-PDUs shall be discarded by the 3G/2G SGSN. 

5.3.2 Inter SGSN 
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Figure 17: PS Handover Preparation Phase; Inter-RAT/mode, 
Inter-SGSN case (UTRAN/GERAN lu ^ GERAN A/Gb) 

1. Based on measurement results and knowledge of the RAN topology, the source RNC/BSS decides to initiate an 
inter RAT/mode PS handover towards the GERAN A/Gb. At this point both uplink and downlink user data flows 
via the tunnel(s): Radio Bearer between the MS and the source RNC/BSS; GTP-U tunnel(s) between the source 
RNC/BSS and the old SGSN; GTP-U tunnel(s) between the old SGSN and the GGSN. 

NOTE 1 : The process leading to the handover decision is outside of the scope of this paper. 

2. The source RNC/BSS sends a Relocation Required (Relocation Type, Cause, Source ID, Target ID, MS 
Classmark 2, MS Classmark 3, Source BSS To Target BSS Transparent Container [RN part]) message to the old 
SGSN. The source RNC/BSS shall set Relocation Type to "UE Involved in relocation of SRNS". 

Target ID contains the ID of the target cell BSS. 

NOTE 2: The Target ID contains the CGI if GERAN is the target cell. Considering that CGI contains only LAI and 
CI, it will be problematic for the SGSN to determine the target cell in PS domain without the RAI. The 
same is valid in case of UTRAN-GERAN PS handover. 

3. The old SGSN determines from the Target ID the type of handover, i.e. intra-SGSN, inter-SGSN or inter- 
RAT/mode handover. In case of Inter-RAT/Inter-SGSN PS handover, the old SGSN initiates the PS Handover 
resource allocation procedure by sending a Forward Relocation Request (IMSI, TEI Control Plane, RANAP 
Cause, MM Context, PDP Contexts, PDP Context Prioritisation, Source BSS To Target BSS Transparent 
Container [RN part]. Target Identification, SGSN Address for control plane) message to the new SGSN. 
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As part of the MM context the following security related information is included: 

• CK UMTS Ciphering Key. 

• IK UMTS Integrity protection Key. 

• KSI Key Set Identifier. 

• MS Network Capability Includes ciphering algorithms supported by the MS. 

The value for Kc (Ciphering key for GPRS) is calculated from the CK and IK and the CKSN (Ciphering Key 
Sequence Number of Kc) takes the same value as KSI. 

The new SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the new 
SGSN to the MS. The lOV-UI parameter generated in the new SGSN and used, as input to the ciphering 
procedure will also be transferred transparently from the new SGSN to the MS. 

When the new SGSN receives the Forward Relocation Request message the required PDP, MM, SNDCP and 

LLC contexts are established and a new P-TMSI is allocated for the MS. The mapping between N-SAPI, SAPI 
and PFI for each PDP Context which is established and provided to the target BSS. When this message is 
received by the new SGSN it begins the process of establishing PFCs for all PDP contexts. 

When the new SGSN receives the Forward Relocation Request message it extracts from the PDP Contexts the 
NSAPIs and possibly the SAPIs to be used in the new SGSN. If no SAPI was available at the old SGSN for a 
certain NSAPI, the new SGNS shall assign a SAPI and the PFI for this NSAPI. In this case the mapping between 
N-SAPI, SAPI and PFI for each PDP Context which is established and provided to the target BSS. 

In case when an SAPI and PFI was available at the old SGSN but the new SGSN does not support the same 
SAPI and PFI for a certain NSAPI as the old SGSN, the new SGSN shall continue the PS handover procedure 
only for those NSAPIs for which it can support the same PFI and SAPI as the old SGSN. All PDP contexts for 
which no resources are allocated by the new SGSN or for which it cannot support the same SAPI and PFI 
(i.e. the corresponding NSAPIs are not addressed in the response message of the target SGSN), are maintained 
and the related SAPIs and PFIs are kept. These PDP contexts may be modified or deactivated by the new SGSN 
via explicit SM procedures upon RAU procedure. 

When the new SGSN receives the Forward Relocation Request message the required PDP, MM, SNDCP and 
LLC contexts are established. 

NOTE 3: In this case XID parameters are not sent from the old SGSN to the new SGSN. 

The new SGSN shall for a given N-SAPI: 

• send an XID Command indicating the new XID parameters and new lOVs to the target BSS; or 

• send an XID Command indicating Reset and new lOVs to the target BSS. 
NOTE 4: The handhng of XID negotiation is as specified in 3GPP TS 44.064 [21]. 

4. The new SGSN sends a PS Handover Request (Local TLLI, IMSI, Target Cell Identifier, Source BSS to Target 
BSS Transparent Container [RN part], PFC(s) To Be Set Up List, XiD Command) message to the target BSS. 
The new SGSN shall not request resources for PFCs associated with PDP contexts with maximum bit rate for 
uplink and downlink of kbit/s. 

NOTE 5: For each N-SAPI associated to a PEC in the PFCs To Be Set Up List, the new SGSN shall provide an 
XID Command. 

Based upon the ABQP for each PEC the target BSS makes a decision about which PFCs to assign radio 
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. 

5. If the target BSS is not able to allocate resources for one or more BSS PFCs it shall send PS Handover BSS 
PFC Status Report (Setup PEC, Failed to Set Up PFCs) message to the new SGSN. 

6. Upon receiving the PS Handover BSS PFC Status Report message the new SGSN sends the XID Command 
for each of the set up PFCs to the target BSS in the PS Handover BSS PFC Status Report Acknowledge (XID 

Command for the set up BSS PFC) message. 
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7. After receiving all the necessary information for the accepted PFCs the target BSS shall prepare the Target BSS 
to Source BSS Transparent Container including the XID Commands only for the set up BSS PFCs. 

8. Target BSS shall send the PS Handover Request Acknowledge message (Local TLLI, Cause, PFCs Setup, 
failed PFCs, Target BSS to Source BSS Transparent Container [RN part, CN part]) message to the new SGSN 
for the accepted PFCs. Upon sending the PS Handover Request Acknowledge message the target BSS shall be 
prepared to receive downlink LLC PDUs from the new SGSN for the accepted PFCs. 

Any PDP contexts for which a PFC was not established will be released. 

9. The new SGSN passes the assigned list of TEIDs for each PDP context for which a PFC was assigned in the 
RAB setup information IE in the Forward Relocation Response (Cause, Target BSS to Source BSS 
Transparent Container [RN part, CN part]). Tunnel Endpoint Identifier Data II) message to the old SGSN. The 
Tunnel Endpoint Identifier Data II, one information for each PDP context, contains the tunnel endpoint of the 
new SGSN and the IP address of the new SGSN for data forwarding from the SRNC to the new SGSN. 

When the old SGSN receives the Forward Relocation Response message and it decides to proceed with the 
handover, the preparation phase is finished and the execution phase will follow. 
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Figure 18: PS Handover Execution Phase; Inter-RAT/mode, 
Inter-SGSN case (UTRAN/GERAN lu ^ GERAN A/Gb) 

1 . The old SGSN continues to receive IP packets from the GGSN (via GTP) and forwards the associated PDU 
payload to the MS via the source RNC/BSS. 

2. The old SGSN continues the PS handover by sending a Relocation Command (Target RNC to Source RNC 
Transparent Container [RN part, CN part], RABS to be Released List, RABs Subject to Data Forwarding List) 
message to the source RNC/BSS. "RABs to be released list" will be the list of all NSAPIs (RAB Ids) for which 
a PFC was not established "RABs Subject to Data forwarding list" will be the list of all NSAPIs (RAB Ids) for 
which a PFC was established. 

3. When receiving the Relocation Command message the source RNC/BSS may, based on QoS, begin the 
forwarding of data for the RABs subject to data forwarding to the new SGSN according to the definition in 
3GPPTS 23.060 [19]. 
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The new SGSN may, based on QoS, proceed with the packet handling as follows: 

• For PDP contexts, which use LLC ABM the new SGSN converts the PDCP sequence number into a Send N- 
PDU number (this is done by stripping off the 8 most significant bits of the PDCP sequence number) and 
stores the N-PDU associated with each Send N-PDU number into the SNDCP queue. Data transfer prior the 
exchange of N-PDU SNs between MS and new SGSN is not possible. 

• For PDP contexts which use LLC ADM the new SGSN either: 

a. forwards the received downlink N-PDUs to the target BSS; 

b. stores the received data into the SNDCP queue for e.g. the PDU lifetime; 

c. discards the received data until e.g. reception of the PS Handover Complete message. 

If the new SGSN forwards packets to the target BSS, the target BSS may start a blind transmission of downlink 
user data towards the MS over the allocated radio channels. 

NOTE: The order of steps, starting from step 3 onwards, does not necessarily reflect the order of events. For 

instance the source RNC may start data forwarding (step 3), send the RRC message (step 5) and send the 
Forward SRNS Context message (step 5a) almost simultaneously. 

4. The source RNC/BSS sends the Handover from UTRAN Command message (UTRAN) or the Handover 
from GERAN lu Command message to the MS. Before sending the message the uplink and downlink data 
transfer shall be suspended in the source RNC for the RABs that require delivery order. 

The PS handover structure encapsulated in this message shall contain for each of the NSAPI for which 
resources are allocated the allocated PFI if the S API was available at the old SGSN and the allocated S API and 
PFI, if no S API and PFI was available at the old SGSN. The MS utilizes the newly assigned S API and PFI 
values for a certain NSAPI in the target cell. Upon reception of the Handover from UTRAN Command 
message (UTRAN) or the Handover from GERAN lu Command the MS shall suspend the uphnk 
transmission of user plane data. 

5. The source RNC continues the handover by sending a Forward SRNS Context (RAB contexts) message to 
the new SGSN, via the old SGSN. The Forward SRNS Context message is acknowledged by the new SGSN 
with the Forward SRNS Context Acknowledge message to the old SGSN. 

The source RNC/BSS behavior is as specified in 3GPP TS 23.060 [19] (Combined Hard Handover and SRNS 
Relocation). 

6. The MS executes the handover according to the parameters provided in the message delivered in step 5. The 
procedure is the same as in step 6 in clause 5.1.4.2 with the additional function of association of the received 
SAPI and PFI and existing RAB Id to the particular NSAPI as described in clause 4.4.1. 

7. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 6, 
the MS immediately sends one XID Response (e.g. lOV) message to the new SGSN for each XID Command 
message received in the source cell, thereby informing the SGSN about the negotiated security parameters. For 
LLC ABM, the XID Response message is followed by a SABM-UA exchange procedure as defined in TS 
44.064. To make the handover interruption short the MS sends this message immediately after receiving the 
Physical Information message or, in the synchronised network case, immediately after the sending of the PS 
Handover Access message. 

Upon successful XID negotiation the MS shall resume the user data transfer only for those NSAPIs for which 
there are radio resources allocated in the target cell. All other NSAPIs shall be handled following the legacy 
procedures during routing area change, thus the MS shall not resume the uplink user data transfer until the 
routing area update procedure is completed. 

8. Upon reception of the first correct RLC/MAC block (sent in normal burst format) the target BSS sends a PS 
Handover Complete (Local TLLI, Handover Complete Status) message to inform the PFM entity in the new 
SGSN that the MS has arrived in the target cell. The source RNC/BSS initiates the release of the radio 
resources in the source cell. After the reception of the PS Handover Complete message the new SGSN shall 
be prepared to receive data from the target BSS. 
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9. The new SGSN sends an Update PDF Context Request (new SGSN Address, TEID, QoS Negotiated) 
message to the GGSN concerned. The GGSN updates the PDP context fields and returns an Update PDF 
Context Response (TEID) message. From now on the GGSN sends new incoming downhnk IP packets only 
to the new SGSN. Each uplink N-PDU received by the new SGSN prior to updating the PDP Context for the 
associated PEC by the Update PDP Context Request message is discarded. Once the new SGSN has updated 
the PDP Context for any given PEC, it starts sending all associated uplink N-PDUs it receives directly to the 
GGSN. 

10. The new SGSN send a Forward Relocation Complete message to the old SGSN to indicate completion of the 
PS handover procedures. The old SGSN responds with a Forward Relocation Complete Acknowledge 

message. 

11. The old SGSN sends an lu Release Command message to the source RNC/BSS commanding the source 
RNC/BSS to release all resources related to the lu connection. When the RNC/BSS data forwarding timer has 
expired the source RNC/BSS responds with an lu Release Complete (RAB Data Volume report list, RABs 
released list) message. 

12. The MS sends a Routing Area Update Request (Old P-TMSI, Old RAI, Old P-TMSI signature. Update Type) 
message to the new SGSN informing it that the source cell belongs to a new routing area. The MS shall send 
this message immediately after message 7, see 3GPP TS 23.060 [19]. 

The new SGSN knows that a handover has been performed for this MS and can therefore exclude the SGSN 
context procedures which normally are used within the RA Update procedure. 

13. At this point the new SGSN may optionally invoke MS authentication (security function). The security 
function can be deferred and performed at any later time as well. 

14. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN 
Address, IMSI) message to the HLR. 

15. The HLR sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN with Cancellation 
Type set to Update Procedure. The old SGSN acknowledges with a Cancel Location Acknowledge (IMSI) 
message. This message allows the old SGSN to know when to release the inter-SGSN tunnel. 

16. The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) message to the new SGSN. The new 
SGSN validates the MS presence in the (new) RA. If all checks are successful then the new SGSN constructs 
an MM context for the MS and returns an Insert Subscriber Data Acknowledge (IMSI) message to the HLR. 
This message allows the new SGSN to know when to release the inter-SGSN tunnel. 

17. The HLR acknowledges the Update Location by sending an Update Location Acknowledge (IMSI) message 
to the new SGSN. 

18. The new SGSN validates the MS presence in the new RA. If the MS is allowed to be attached in this RA, the 
SGSN updates the MM context for and sends a Routing Area Update Accept (P-TMSI, TMSI, P-TMSI 
signature. Receive N-PDU number) message to the MS. The Receive N-PDU Number contains the 
acknowledgements for each acknowledged-mode NSAPI used by the SGSN, thereby confirming all mobile 
originated N-PDUs successfully transferred before the start of the PS handover procedure. 

19. The MS confirms the re-allocation of the new P-TMSI by responding the SGSN with a Routing Area Update 
Complete (Receive N-PDU number). The MS derives the Local TLLI from the new P-TMSI using the current 
MM procedures. The Receive N-PDU Number contains the acknowledgements for each acknowledged mode 
NSAPI used by the MS, thereby confirming all mobile terminated N-PDUs successfully transferred before the 
start of the handover procedure. If Receive N-PDU Number confirms reception of N-PDUs that were 
forwarded from the old SGSN, these N-PDUs shall be discarded by the new SGSN. 
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5.4 Handover reject 

5.4.1 General 

The target BSS may reject the use of the PS Handover procedure in case it cannot allocate resources for any of the PFCs 
requested in the PS Handover Request message. In this case no MS context will be established in the target BSS and 
no resources will be allocated. The target BSS will send a PS Handover Reject message to the new SGSN causing the 
new SGSN to release any allocated resources (e.g. P-TMSI, MS associated contexts) related to the specific MS. The 
signalling procedure for the Inter-SGSN HO Reject is shown in clause 5.3.4.5.2. Similar procedures are used in the 
other handover cases. 

5.4.2 Inter-SGSN HO Reject; Signalling procedure 
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Figure 19: PS Handover Reject; Inter-SGSN case (GERAN A/Gb ^ GERAN A/Gb) 

1 . The first four steps in the flow are identical to the ones in clause 5. 1 .4. 1 . 

2. In case the target BSS fails to allocate any resources for any of the requested PFCs it sends a PS Handover 
Reject (Cause, Source Cell Identifier, Target Cell Identifier) message to the new SGSN. 

3. When the new SGSN receives the PS Handover Request Reject message it clears any reserved resources 
(e.g. PDP context, P-TMSI) for this mobile and sends the Forward Relocation Response (IMSI, Cause, Source 
Cell Identifier, Target Cell Identifier, SGSN Address) message to the old SGSN. 

4. When the old SGSN receives the Forward Relocation Response message it sends a PS Handover Required 
Reject (Old TLLI, Cause, Source Cell Identifier, Target Cell Identifier) message to the source BSS. 



5.5 



Handover cancel 



5.5.1 General 

Instead of performing the handover, the source BSS may at any time during the handover procedure up to the time when 
the PS Handover Command is sent to the mobile station cancel the handover. The reason for canceling can be e.g. due 
to a timer expiration or due to other events within the source BSS and is initiated by sending a PS Handover Cancel 
message to the SGSN. 

A PS Handover Cancel message shall also be sent by the source BSS after the PS Handover Command message is 
sent to the mobile station for the case where the PS Handover fails and the MS returns to the old cell. This is done in 
order to release the resources reserved for the PS Handover in the target system. 
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The signalling procedure for the Inter-RAT Handover Cancellation is shown in clause 5.3.4.5.2. Similar procedures are 
used in the other handover cases. 

5.5.2 Inter-RAT Cancellation; Signalling procedure 
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Figure 20: PS Handover Cancel; Inter-RAT case (GERAN -^ UTRAN) 

1. The source BSS decides to cancel the previously requested PS handover. This may be due to failed coordination 
with the CS domain, not enough accepted PFCs, dropped mobile, that the source has requested several target 
cells simultaneously or any other reason. 

2. The source BSS sends a PS Handover Cancel (TLLI, Source Cell Identifier, Target ID) message to the old 
SGSN. 

3. The old SGSN terminates the PS Handover to the target cell by sending a Relocation Cancel Request (IMSI) 
message to the new SGSN. 

NOTE 1: If one new SGSN was chosen among a pool, then the Abort message is sent to the same SGSN. 

4. The new SGSN clears the reserved resources in the target cell by sending an lu Release Command (Cause) 
message to the target RNC. 

NOTE 2: In case of GERAN A/Gb to GERAN A/Gb handover it is assumed that existing BSS Packet Flow 
procedures could be used to clear all reserved resources and MS context in the target BSS. 

5. After all resources are cleared, the target RNC shall send the lu Release Complete (RAB Data Volumes, RABs 
released) message to the new SGSN. 



5.6 Container handling 



There are two transparent containers defined for the PS handover in GERAN A/Gb mode: 

• Source BSS to Target BSS Transparent Container. 

• Target BSS to Source BSS Transparent Container. 

The Source BSS to Target BSS Transparent Container will carry the information to be transported transparently 
between the source BSS and the target BSS related to PS handover. 

The Target BSS to Source BSS Transparent Container will carry the information to be transported transparently 
between the target BSS and the source BSS related to PS handover. 
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In case of the inter-RAT/mode PS handover the transparent containers defined for UTRAN/GERAN lu mode (Source 
RNC to Target RNC Transparent Container and Target RNC to Source RNC Transparent Container) will be utilized and 
enhanced with new information elements to support PS handover. 

The generic handling of the source cell (GERAN A/Gb mode or UTRAN/GERAN lu mode) to target cell (GERAN 
A/Gb mode or UTRAN/GERAN lu mode) radio-related container is as follows: 

• Created by the source BSS or RNC. 

• Processed by the target BSS or RNC. 

• Forwarded transparently by the SGSNs. 

The generic handling of the target cell (GERAN A/Gb mode or UTRAN/GERAN lu mode) to source cell (GERAN 
A/Gb mode or UTRAN/GERAN lu mode) radio-related container is as follows; 

• Created by the target BSS or RNC. 

• Processed by the source BSS or RNC. 

• Forwarded transparently by the SGSNs. 

5.6.1 Contents of the containers 

The transparent container will consist of two parts: 

• The Radio Network part (RN part) carrying radio interface related parameters relevant for the MS and the radio 
network (BSS/RNC) and sent transparently through the core network; This content is: 

- Created by the source BSS/RNC or target BSS/RNC. 

Processed by the target BSS/RNC, source BSS/RNC and MS (reverse container only). 

• The Core Network part (CN part) carrying parameters relevant for the MS and the core network. This part is 
only needed from the new SGSN to the MS, thus in the Target BSS to Source BSS Transparent Container. This 
content is: 

- Created by the new SGSN. 

Included in the Target BSS to Source BSS Transparent Container by the target BSS. 
NOTE 1: The target BSS does not process the Core Network part. 

Forwarded transparently by the old SGSN and source BSS/RNC. 
Processed by the MS. 
The contents of the Radio Network part will depend on: 

• Type of channels that are subject to PS handover, i.e. shared or dedicated. 

NOTE 2: Currently dedicated channels are not considered in the PS handover in GERAN A/Gb mode. 

• PS handover scenario, i.e. intra-mode or inter-RAT/mode. 

The contents of the Core Network part will depend on the PS handover scenario, i.e. intra-mode or inter-RAT/mode. 

5.6.1 .1 Contents of the GERAN A/Gb mode -^ GERAN A/Gb Transparent 

Containers 

5.6.1 .1 .1 Source BSS to Target BSS Transparent Container 

In GERAN A/Gb mode -> GERAN A/Gb mode the Source BSS to Target BSS Transparent Container is sent in the PS 
Handover Required, Forward Relocation Request message and the PS Handover Request message. 
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The Radio Network part consists of the following: 

• MS RAC. 

• START_PS and UE RAC (for dual mode mobile stations). 

NOTE 1: The START_PS and UE RAC are needed to support PS Handover to UTRAN/GERAN lu mode. 
NOTE 2: The procedure to get the START_PS and UE RAC values from the MS to the BSS needs to be defined. 

5.6.1 .1 .2 Target BSS to Source BSS Transparent Container 

In GERAN A/Gb mode -> GERAN A/Gb mode the Target BSS to Source BSS Transparent Container is sent in the PS 
Handover Request Acknowledge message, Forward Relocation Response message and the PS Handover 
Command message. 

The Radio Network part consists of the required information for access in the target cell and the information on 
allocated radio resources, uplink and downlink TBF parameters, PS Handover reference and generic parameters for 
access in the target cell (i.e. GPRS cell options, target cell "Cell Selection struct", global power control parameters, 
reference frequency lists, cell allocation, GPRS mobile allocation). 

The Core Network part consists of the XID Commands for the BSS PFCs set up in the target BSS. 

5.6.1 .2 Contents of the GERAN A/Gb mode -^ UTRAN Transparent Containers 

5.6.1 .2.1 Source RNC to Target RNC Transparent Container 

In GERAN A/Gb mode -> UTRAN the Source RNC to Target RNC Transparent Container is sent from the source BSS 
to the target RNC in the PS Handover Required message and the Relocation Request message. 

The Radio Network part consists of the following: 

• RRC Container as defined in 3GPP TS 25.33 1 [17] will contain Inter RAT Handover Info (UTRAN specific 
information including START_PS/UE RAC) and Inter RAT UE radio access capability including MS RAC from 
BSS to RNC. 

NOTE: START_PS and MS RAC are currently not included in this RRC container. This thus needs to be added 
in 3GPPTS 25.331 [17]. 

• Target Cell Id. 

5.6.1 .2.2 Target RNC to Source RNC Transparent Container 

In GERAN A/Gb mode -> UTRAN the Target RNC to Source RNC Transparent Container is sent from the target RNC 
to the source BSS in the Relocation Request Acknowledge message. Forward Relocation Response message and the 
PS Handover Command message. 

The Radio Network part consists of the RRC message, i.e. the Handover to UTRAN Command message (as defined 
in 3GPP TS 25.331 [17]) used to perform handover from GERAN A/Gb mode to UTRAN. This message will be sent to 
the MS/UE within the PS Handover Command message. 

5.6.1 .3 Contents of the UTRAN -^ GERAN A/Gb Mode Transparent Containers 
5.6.1 .3.1 Source BSS to Target BSS Transparent Container 

In UTRAN -> GERAN A/Gb mode the Source BSS to Target BSS Transparent Container is sent from the source RNC 
to the target BSS in the Relocation Required, Forward Relocation Request message and the PS Handover Request 

message in order to support inter-RAT PS handover from UTRAN (CELL_DCH state or CELL_FACH state, only PS 
RABs established) to GERAN A/Gb mode. 

The Radio Network part consists of the following information: 
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• MS RAC. 

• INTER RAT HANDOVER INFO (defined in 3GPP TS 25.33 1) containing the START_PS and UE RAC values. 

5.6.1 .3.2 Target BSS to Source BSS Transparent Container 

In UTRAN -> GERAN A/Gb mode the Target BSS to Source BSS Transparent Container is sent fi^om the target BSS to 
the source RNC in the PS Handover Request Acknowledge message, Forward Relocation Request message and the 
Relocation Command message in order to support inter-RAT PS handover from UTRAN (CELL_DCH state or 
CELL_FACH state, only PS RABs estabUshed) to GERAN A/Gb mode. 

The Radio Network part consist of the required information for access in the target cell and the information on 
allocated radio resources: uplink and downlink TBF parameters, PS Handover reference and generic parameters for 
access in the target cell (i.e. GPRS cell options, target cell "Cell Selection struct", global power control parameters, 
reference frequency lists, cell allocation, GPRS mobile allocation). Over the air interface this radio network container is 
sent within the Handover from UTRAN Command message. 

The Core Network part consist of the following: 

• XID Command for the PDP Contexts for which the BSS PFCs are set up in the target BSS. 

• The associated SAPI and PFI for each NSAPI. 

5.6.1 .4 Contents of the GERAN A/Gb mode -^ GERAN lu mode Transparent 
Containers 

5.6.1 .4.1 Source RNC to Target RNC Transparent Container 

In GERAN A/Gb mode -> GERAN lu mode the Source RNC to Target RNC Transparent Container is sent from the 
source BSS to the target BSS (lu) in the PS Handover Required message, Forward Relocation Request message and 
the Relocation Request message. 

The Radio Network part consists of: 

• RRC Container as defined in 3GPP TS 44.1 18 [16] shall contain START_PS /MS GERAN lU capabiHties. 

• Target Cell Id. 

5.6.1 .4.2 Target RNC to Source RNC Transparent Container 

In GERAN A/Gb mode -> GERAN lu mode the Target RNC to Source RNC Transparent Container is sent from the 
target BSS (lu) to source BSS in the Relocation Request Acknowledge message. Forward Relocation Response 
message and the PS Handover Command message. 

The Radio Network Part consist of the RRC message used in GERAN lu mode to perform handover, i.e. Radio Bearer 
Reconfiguration message as defined in 3GPP TS 44.118 [16]. This message will be sent to the MS in the PS 
Handover Command message. 

5.6.1 .5 Content of GERAN lu mode -^ GERAN A/Gb mode Transparent Containers 
5.6.1 .5.1 Source BSS to Target BSS Transparent Container 

In GERAN lu mode -> GERAN A/Gb mode the Source BSS to Target BSS Transparent Container is sent from the 
source BSS (lu) to the target BSS in the Relocation Required message. Forward Relocation Request message and 
the PS Handover Request message. 

The Radio Network part consists of the following: 

• MS RAC. 

• INTER RAT OR MODE HANDOVER INFO with MS capabilities as defined in 3GPP TS 44. 1 18 [16]. 
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NOTE: START_PS and UE RAC shall be added to this IE. 

5.6.1 .5.2 Target BSS to Source BSS Transparent Container 

In GERAN lu mode -> GERAN A/Gb mode the Target BSS to Source BSS Transparent Container is sent from the 
target BSS to the source BSS (lu) in the PS Handover Response message, Forward Relocation Request message and 
the Relocation Command message in order to support PS handover to GERAN A/Gb mode from GERAN lu mode 
(RRC CelLDedicated state or RRC CELL_Shared state, only PS RABs established). 

The Radio Network part consists of the required information for access in the target cell and the information on 
allocated radio resources: Uplink and downlink TBF parameters, PS Handover reference and generic parameters for 
access in the target cell (i.e. GPRS cell options, target cell "Cell Selection struct", global power control parameters, 
reference frequency lists, cell allocation, GPRS mobile allocation). Over the air interface this information is sent in the 
Handover from GERAN lu mode Command message. 

The Core Network part consists of the following: 

• XID Command for the PDP Contexts for which the BSS PFCs are set up in the target BSS. 

• the associated SAPI and PFI for each NSAPI. 

5.7 PS Handover Failure 

During the PS handover procedure several types of failures can be identified. The PS handover failures may be typical 
network and signalling failure occurrences such as failures related to the loss of signalling messages, incorrect 
information element in the signalling messages or failures due to network nodes failures or specific to abnormal cases 
occurring during PS handover procedures. 

In general the PS handover failures can be divided into: 

• Preparation Phase Failure Scenarios on the Um, Gb and Gn interface. 

• Execution Phase Failure Scenarios on the Um, Gb and Gn interface. 

NOTE: RAU procedure failures will be handled as specified in 3GPP TS 24.008 [15]. 

A list of appropriate cause values should be chosen/defmed to indicate to the source cell and target cell nodes the cause 
of the PS Handover Reject and the PS handover Cancel messages. 

5.7.1 Preparations Pinase Failure Scenarios 

5.7.1 .1 PS Handover preparation phase failure scenarios on the Um interface 

• No Resource Reservation / Allocation: 

No radio resources available in the target cell (see clause 5 in 3GPP TS 43.129 [24]). 

• Generic Causes: 

Generic causes, described and handled as defined in 3GPP TS 44.060 [7], for example failure in sending the 
Packet Cell Change Failure message from the MS to the source BSS. 

5.7.1 .2 PS Handover preparation phase failure scenarios on the Gb interface 

• No Resource Reservation / Allocation on the target system: 

No radio resources available in the target cell (see clause 5.4). Appropriate cause values are needed in the PS 
Handover Reject message. 

• Insufficient resource allocation by the target system: 
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In case of insufficient resource allocation by the target side the source BSS may cancel the PS handover 
procedure (see clause 5.5). 

• Feature "PS Handover" not supported: 

A new cause value is needed for the Gb interface if the target BSS does not support the PS Handover 
procedure. 

• Generic Causes: 

Generic causes for the Gb interface failures are defined in 3GPP TS 48.018 [10]. The same cause values are 
applicable to the PS handover procedure on the Gb interface. 

5.7.1 .3 PS Handover preparation phase failure scenarios on the Gn interface 

• Context Transfer Failure: 

Context transfer failure may occur due to various causes defined in 3GPP TS 29.060 [11]. These cause values 
will be utilized during PS handover procedure. These values are to be utilized during PS handover procedure 
to indicate to the old SGSN the cause of the PS handover reject. Consequently an appropriate cause value 
should be chosen to allow the old SGSN to indicate to the source BSS the cause of failure. 

• No Resource Reservation/ No Resource Allocation: 

Resource Reservation/ Allocation failure occurs when no radio resources are available in the target cell. 
Consequently an appropriate cause value should be chosen to allow the old SGSN to indicate to the source 
BSS the cause of failure. 

• Procedure "PS Handover" not supported: 

This occurs when the new SGSN does not support the PS Handover feature. 

• Generic Causes: 

In 3GPP TS 29.060 [1 1] a set of cause values are defined. The same cause values are applicable to the PS 
handover procedure on the Gn interface. 

5.7.2 Execution Phase Failure Scenarios 
5.7.2.1 Execution phase failures on the Urn interface 

• Initial Access Failure in the Target Cell during PS handover: 

In case of initial access failure in the target cell, the MS is allowed to revert to the old cell. As is defined 
currently in 3GPP TS 44.060 [7], the MS shall return to the old cell and send a Packet Cell Change Failure 
message with the appropriate cause. If the MS was involved in simultaneous uplink and downlink packet 
transfer mode (or MAC-shared state) before the attempted handover it will, when going back to the old cell, 
send a Packet Cell Change Failure message and continue its uplink transfer. The source BSS will inform 
the old SGSN about this failure and consequently the old SGSN will inform the new SGSN about this failure, 
upon which the new SGSN will release the allocated resources and clear out any information and buffers 
related to this MS. 

• Synchronization Failure in the Target Cell: 

This failure may occur during the ongoing PS Handover procedure due to MS failure to acquire time 
alignment information (for the unsynchronised network case). In this case the MS goes back to the old cell as 
described above. 

The signalling flow for this procedure is depicted in figure 21 . 
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Figure 21 : Initial target cell access failure; Inter-SGSN case 

5.7.2.2 Execution phase failures on the Gb interface 

• Generic Causes: 

Generic causes for the Gb interface failures are defined in 3GPP TS 48.018 [10]. The same cause values are 
applicable to the PS handover procedure. 



5.7.2.3 



Execution phase failures on the Gn interface 



Update PDP Context failure: 

- As specified in 3GPP TS 29.060 [11] if the new SGSN receives an Update PDP Context Response message 
from the GGSN with a cause value other than 'Request accepted', it shall abort the update of the PDP context. 
In this case the new SGSN shall inform the old SGSN that the PS handover has been aborted with an 
appropriate cause value upon which the old SGSN will initiate the deletion of the resources. The new SGSN 
will initiate the deletion of the resources in the target BSS. 



6 Radio interface Signalling 

6.1 PS Handover Signalling (Um) 

6.1.1 General 

PS Handover signalling includes the set of all air interface messages (Um signalling for A/Gb mode and Uu signalling 
for lu mode) sent to or from the MS in the source and target cells during the PS handover procedure. 

6.1 .2 Overview of PS Handover messages 



6.1.2.1 



GERAN A/Gb mode to GERAN A/Gb mode PS Handover 



When performing an inter-SGSN PS Handover from GERAN A/Gb mode to GERAN A/Gb mode the following 
information is sent over the Um interface. 

• PS Handover Command message - sent to the MS in the source cell and includes the following: 

System broadcast information applicable to the target cell. This information may be provided by the target 
BSS in the Target BSS to Source BSS Transparent Container. 
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Indication of the XID parameters (e.g. as specified within an XID Command message as defined in 
3GPP TS 44.064 [21]) to be used for each unique SAPI associated with all PDP Contexts forwarded to the 
new SGSN. If layer 3 parameters are included in the XID parameters (e.g. data compression algorithm) and 
multiple N-SAPIs map to a common SAPI then the layer 3 parameters must indicate the specific N-SAPI 
associated with a given set of layer 3 parameters. 

Indication of the radio resources for uplink and downlink TBFs to be used in the target cell for each PFC 
receiving PS handover treatment (i.e. the reverse path container created by target BSS/RNC). 

Indication of a PS handover reference number to be used when the MS arrives in the target cell. 

• PS Handover Access message - the MS sends 4 handover access bursts in the target cell using an uplink TBF 
provided by the PS Handover Command. If multiple uplink TBFs are provided by the PS Handover Command 
message the MS sends access bursts using just one of these TBFs (i.e. at minimum one uplink TBF must be 
provided in the PS Handover Command message). The handover reference number is included within each 
access burst. This message is always sent for the case of unsynchronised cells and may still be sent for the case 
of synchronised cells (determined by the target BSS during the PS handover preparation phase) to allow the 
target BSS to verify the accessing MS. 

• Physical Layer Information message - sent by the target BSS to the MS in the target cell in response to the PS 
Handover Access message for the case of unsynchrorused cells. Whether or not this message is sent in case of 
synchronised cells is indicated by the PS Handover command message (see 3GPP TS 44.018 [25]). It is sent 
using the downlink PACCH associated with the uplink TBF used to send the access bursts and provides the MS 
with physical layer information (i.e. time alignment information - see 3GPP TS 23.108 [20]). The time 
alignment information received in this message applies to all uplink TBFs allocated to the MS in the PS 
Handover Command message. The target BSS only sends this information if it receives the expected handover 
reference number in the access bursts (the same value must be present in each of the 4 access bursts). 

• Uplink RLC Data Blocks - sent on uplink TBFs allocated by the PS Handover Command message after the 
MS receives Physical Layer Information message as follows: 

For inter-SGSN PS handover the MS, prior to sending any uplink user plane payload for any PFC, shall send 
an XID Response for those PFCs that it has received an XID Command message. 

• Downlink RLC Data Blocks - sent on downlink TBFs allocated by the PS Handover Command message as 
follows: 

For inter-SGSN PS handover for a given PFC the new SGSN may begin downlink N-PDU transmissions for 
that PFC prior to receiving a PS Handover Complete message, a Routing Area Update Request message 
from the MS or an XID Response message for that PFC (i.e. blind transmission may be used) or it may wait 
for a PS Handover Complete message before beginning downlink N-PDU transmissions for that PFC. 

6.1 .2.2 UTRAN/GERAN lu mode to GERAN A/Gb mode PS Handover 

When performing a PS Handover from UTRAN/GERAN lu mode to GERAN A/Gb mode the following information is 
sent over the Uu and Um interfaces: 

• RRC Message - sent to the MS in the source cell and includes the same information described for the PS 
Handover Command in clause 6.1.2.1. 

• For PS handover from UTRAN the Handover from UTRAN Command (3GPP TS 25.331 [17]) message is used 
in CELL_DCH and CELL_FACH state when only PS RABs are established. 

• For PS handover from GERAN lu mode the HANDOVER FROM GERAN lU COMMAND message is used in 
RRC-Cell_Dedicated (MAC Dedicated or MAC DTM state) or RRC-Cell_Shared state when only PS RABs are 
established. 

• PS Handover Access message - sent as described in clause 6. 1.2.1. 

• Physical Layer Information message - sent as described in clause 6.1.2.1. 

• Uplink RLC Data Blocks - sent as described in clause 6.1.2.1. 

• Downlink RLC Data Blocks - sent as described in clause 6.1.2.1. 
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6.1 .2.3 GERAN A/Gb mode to GERAN lu mode PS Handover 

When performing a PS Handover from GERAN A/Gb mode to GERAN lu mode the following information is sent over 
the Uu and Um interfaces: 

• PS Handover Command message - sent to the MS in the source cell and includes the following: 

System broadcast information applicable to the target cell. 

Indication of the radio resources for uplink and downlink TBFs to be used in the target cell for each RAB 
receiving PS handover treatment (i.e. the reverse path container created by target ESS). Note that the MS will 
map the N-SAPI associated with each of its active PDP Contexts directly to a RABid (i.e. N-SAPI = RABid). 

Indication of a PS handover reference number to be used when the MS arrives in the target cell. 

• PS Handover Access message - sent as described in clause 6. 1.2.1. 

• Physical Layer Information message - sent as described in clause 6.1.2.1. 

• RRC message (e.g. Physical Channel Reconfiguration Complete) - content is GERAN lu mode specific. 

• Uplink RLC Data Blocks - sent on uplink TBFs allocated by the PS Handover Command after the MS receives 
Physical Layer Information (content is GERAN lu mode specific). 

• Downlink RLC Data Blocks - sent on downlink TBFs allocated by the PS Handover Command (content is 
GERAN lu mode specific). 

6.1 .2.4 GERAN A/Gb mode to UTRAN mode PS Handover 

When performing a PS Handover from GERAN A/Gb mode to UTRAN mode the following information is sent over 
the Uu and Um interfaces: 

• INTER SYSTEM TO UTRAN PS HANDOVER COMMAND - an RLC/MAC control message sent to the MS 
in the source cell. It includes the reverse path container created by the target RNC that consists of the RRC 
message (i.e. the Handover to UTRAN Command) required to perform PS handover to UTRAN. 

• MS Detected by Target RNC - exact procedure and information transfer is UTRAN specific. 

• RRC message (e.g. Physical Channel Reconfiguration Complete) - information content is UTRAN specific. 



6.1 .3 RLC/MAC segmentation 



RLC/MAC segmentation is a feature that provides an additional mechanism for sending control plane messages from 
the BSS to the MS. This feature can only be used after contention resolution is completed in the BSS and the BSS has to 
send an RLC/MAC control message that is from 3 to 9 radio blocks long. 

6.1 .4 Inter RAT/mode PS Handover to GERAN A/Gb 

Void. 

6.1 .5 Inter RAT/mode PS Handover from GERAN A/Gb 

Void. 
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6.2 Mechanisms for Initial Access in the Target Cell 
6.2.1 General 

This clause describes two possible approaches to the MS making access in the target cell. Both basic approaches assume 
that a handover procedure similar to that for the CS domain (Handover Access followed by Physical Information 
messages) takes place. 

The effect of synchronised networks is examined for both approaches where the exchange of Handover Access and 
Physical Information is not required as the TA can be derived in advance. 

The main assumptions applicable to the call flows are: 

• USFs are required to schedule uplink data blocks. 

• All identifiers and resources are known by the MS and target BSS before the MS makes the initial access in the 
target cell. 



6.2.2 Synchronisation of cells 



The same synchronisation mechanisms as used for handover in GSM are used for PS handover. The four cases in GSM 
are: 

• Non- synchronised cells. 

• Finely Synchronised cells. 

• Pseudo Synchronised cells. 

• Pre-Synchronised cells. 

The non-synchronised cases are shown in figures 22 and 24 and are characterised by the requirement for the MS to 
obtain a valid uplink timing advance before it can transmit normal bursts. The MS shall notify its presence in the target 
cell through the transmission of access bursts to the BSS, and the BSS shall respond with a valid timing advance which 
in turn enables the MS to send normal bursts in uplink. 

The synchronised cases (finely synchronised, pseudo synchronised and pre-synchronised) are shown in figures 23 and 
25 and all have different mechanisms for the provision of the timing advance that are described in detail in 
3GPP TS 44.018 [25] and 3GPP TS 45.010 [26]. The PS Handover feature will reuse the same solutions. 

6.2.3 Option 1 - Downlink Data sent after performing access in the target 
cell 

In this approach, downlink data is not transmitted until the BSS has been made aware of the presence of the MS via the 
reception of a PS Handover Access message. 

6.2.3.1 Unsynchronised Networks Call Flow 

The message flow for this option is shown in figure 22. The MS starts by sending PS Handover Access messages as 
four access bursts to the network. As there is no contention, the network should receive at least one of the access bursts. 
A Handover Reference parameter is allocated by the target BSS in the PS Handover Command message and included 
in the PS Handover Access message to verify that the correct MS is accessing the resources. This is similar to the 
Handover Reference in the CS handover case. 

The BSS receives the PS Handover Access message and detects that the correct MS has now made access in the target 
cell. It sends a message to indicate that the MS has been detected. The main purpose of this message is to give the 
Timing Advance information to the MS. In this case a message similar to the Physical Information message defined 
for CS handover can be used. It is called the Packet Physical Information message. 
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Once the MS has received the Packet Physical Information message it sends an XID Response message to the new 
SGSN for each PFC subject to PS handover. When correctly receiving the first RLC data block from the MS the target 
BSS verifies the mobile station generates a PS Handover Complete message and sends it to the new SGSN. 

As soon as the XID Response message is sent the MS can start sending uplink RLC/MAC data blocks on the pre- 
allocated resources when scheduled with its USF. When the XID Response message has arrived in the new SGSN the 
SGSN can start sending downlink data blocks. 

Note: It is in case assumed that downlink RLC data blocks are sent for a PFC receiving PS handover treatment after the 
target BSS has confirmed that the correct MS is present and after the PS Handover Complete message has been 
received by the new SGSN for that PFC. 



MS 



BSS 



First downlink data 
blocl< received 



First uplinl< data 
blocl< sent 



[UL PDCH] 



[DL PDCH] 



[UL PDCH] 



[UL PDCH] 



[DL PDCH] 



1 Pacl<et Handover Access 



2 Packet Physical Information (includes TA) 



3 First correctly received RLC/IVIAC block 



(XID Resp., RAU req. or Cell Update) 



4 DL Data Block 



5 UL Data Block 



Figure 22: Option 1 - Downlinit Data after IVIS contacts networit 



6.2.3.2 



Synchronised Networks Call Flow 



In the case of synchronous networks it is possible for the MS to calculate the TA of the target cell before it moves from 
the source cell. 

Figure 23 shows the call flow in the case of synchronous networks. In this case it is possible for the MS to start 
transmitting and receiving messages as soon as it switches to the target cell. 

As described in 3GPP TS 44.018 [25], handover access bursts may optionally be sent if indicated in the handover 
command message. If no access bursts are sent the first message sent in the uplink may be one of the XID Response, 
RAU Request or Cell Update messages. This message is only sent to verify the MS's presence in the new cell but does 
not trigger the sending of any Physical Information message. As blind transmission in the downlink is not being used 
in this scenario, the BSS must wait until a message is received before transmitting data in the downlink. This means that 
the MS cannot send the first uplink data block until it receives the USF in the first downlink data block. 
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MS 



BSS 



First downlink data 
blocl< received 



[DL PDCH] 



[UL PDCH] 



1 PS Handover Access (optional) 




2 DL Data Block 




3 First correctly received RLC/MAC block ^ 


(XID Resp., RAU req. or Cell Update) 
4 UL Data Block 









Wait for UL 
message before 
sending DL data 



First uplink data [UL PDCH] 

block sent 



Figure 23: Option 1 - Downlinl< Data after IVIS contacts networl<, Synchironous Networl<s 

6.2.4 Option 2 - Downlink Data sent before performing access in tine 
target cell (Blind Transmission) 

Blind transmission aims at minimising the interruption time on the downlink following handover. The target BSS starts 
transmitting downlink data on the newly reserved resources in the target cell before the MS has synchronised with this 
cell (i.e. prior to receiving timing advance in the Packet Physical Information message). The message flow for this 
scheme is shown in figure 24. 



6.2.4.1 



Unsynchronised Networks Call Flow 



As the BSS must send the Packet Physical Information as an immediate response to the Packet Handover Access 
message, it is unable to send any downlink data at the same time. Therefore the BSS interrupts delivery of downlink 
data in order to send the Packet Physical Information to the MS. 



MS 



BSS 



First downlink data 
block received 



[DL PDCH] 


1 DL Data Block 


[UL PDCH] 


2 Packet Handover Access 


[DL PDCH] 
[UL PDCH] 


3 Packet Physical Information (includes TA) 


4 First correctly received RLC/I\/IAC block 


[UL PDCH] 


(XID Resp., RAU req. or Cell Update) 
5 UL Data Block 





First uplink data 
block sent 



NOTE 1 : DL data is shown as being sent before the Packet Handover Access, but it may be sent by the target BSS 

at any time in the sequence. The PS Handover Access message is sent when being scheduled with the 

USF. 
NOTE 2: Blind transmission assumes that the downlink data flow for a PFC receiving PS handover treatment may 

begin before the new SGSN receives the associated PS Handover Complete message from the target 

BSS and before the RAU procedure has started. 

Figure 24: Option 2 - Blind Transmission in target cell 
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6.2.4.2 



Synchronised Network Call Flow 



In the case of blind transmission with synchronous networks, downlink data can be sent at the earliest opportunity. This 
is similar to the case for blind transmission without synchronous networks. However, uplink data transfer is also 
sped-up as shown in the call flow of figure 25. 



MS 



BSS 



1 DL Data Block 



2 PS Handover Access (optional) 




3 First correctly received RLC/MAC block 
(XID Resp., RAU req. or Cell Update) 

4 UL Data Block 



These messages 
sent at the 
same time 



[DL PDCH] 



[UL PDCH] 

First downlink data 

block received [DL PDCH] 



First uplink data 

block sent [UL PDCH] 



Figure 25: Option 2 - Blind Transmission in target cell, Synchronous Networks 

The first uplink data sent will consist of either the PS Handover Access message (optional) or one or more RLC data 
blocks that may contain the XID Response message, RAU Request message or the Cell Update message. This case is 
therefore the best in terms of reduced service interruption time. 

As described in 3GPP TS 44.018 [25], handover access bursts may optionally be sent if indicated in the handover 
command message. 

NOTE: Blind transmission assumes that the flow of downlink data for a PFC receiving PS handover treatment 
may begin before the new SGSN receives the associated PS Handover Complete message from the 
target BSS and before the RAU procedure has started. 

6.3 Methods for triggering PS Handover 

A PS Handover is triggered by the BSS based on the received measurement reports or initiated by the reception of the 
Packet Cell Change Notification message from the mobile station. The BSS controls which of the two methods to use 
for initiating the PS Handover. 

When PS Handover is triggered by the BSS based on the measurement reports, the mobile station is in NC2 mode. The 
mobile station sends measurement reports to the network (BSS). When the network has found a new cell meeting the 
cell reselection criteria, and prepared for the PS Handover in that target cell, it sends the PS Handover Command 

message to the mobile station. 

If not in NC2 mode, the mobile station may, by transmitting a Packet Cell Change Notification message according to 
the Cell Change Notification procedure, make the BSS aware it has found a new cell meeting the cell reselection 
criteria. The network then prepares for the PS Handover in the indicated target cell and sends the PS Handover 
Command message to the mobile station. In order to avoid that the mobile station performs autonomous cell 
reselection due to timeout of T3208, the network can order the mobile station to enter NC2 mode by transmitting the 
Packet Measurement Order message in response to the PCCN message. This will keep the mobile station in the cell 
until the PS Handover Command message is sent by the network, thus making it possible for the network to perform 
all necessary PS handover signalling and set up the radio resources in the target cell. 
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Annex A (normative): 
Agreed handover principles 

A.1 Agreed handover principles 

1 . It is the mobile station that is handed over to a target cell when one or more of its PFCs are subject to 
handover. 

2. The source BSS makes the decision to initiate the handover preparation phase when required for PFC(s) 
subject to handover. 

3. Information pertaining to all PDP contexts and PFCs relating to the MS should be sent from the old SGSN to 
the target SGSN in the handover signalling regardless of their QoS. 

4. The target BSS should make the final decision on which PFCs are subject to handover and to assign resources 
over the Um interface in the target cell. This decision is based on the target BSS being able to fulfil the QoS for 
these PFCs. 

5. The old SGSN decides whether and when to forward data to the TEIDs provided by the new SGSN. 

6. It is not required to have resources allocated in advance for bearers which themselves are not determined to be 
subject to handover by the target BSS. 

7. How the target BSS decides which PFCs to accept and which to reject should be implementation specific. 

8. For the PS Handover, forwarding of data is performed from the old SGSN either to the target BSS (intra BSS, 
intra SGSN-inter BSS) or to the new SGSN (inter SGSN); an optional optimisation for intra BSS handover will 
allow the BSS to decide how to handle the user data flow. 

9. An explicit Routing Area Update procedure is performed (if required) when the handover procedure is 
terminated. 

10. The explicit RAU may not contain the following message sequences that are performed already during the 
handover procedure: 

Transfer of contexts between SGSNs (inter SGSN case). 

Exchange of SNDCP sequence numbers (inter SGSN case). 

- Allocation of P-TMSI. 

1 1 . Uplink and downlink data transfer continues during the Routing Area Update procedure. This is possible 
because certain RAU centric functions are performed during the handover execution phase. 

12. The PS Handover service shall support intra BSS, intra SGSN-inter BSS, inter SGSN and inter RAT scenarios. 

13. Based on the quality of service parameters the MS or the network may throw away packets available for 
transmission in the uplink or downlink during the ongoing handover procedure. 

14. The source BSS shall only request PS handover for one cell in each PS Handover Required message. 

15. The PS handover procedure is only performed when the target BSS pre-allocates resource for at least one PFC. 
In case the target BSS cannot allocate resources for at least one PFC the target BSS shall reject the PS 
Handover request using the PS Handover Reject message. 

16. In case the mobile fails to synchronize to the target cell within a timeout period after having received a PS 
Handover Command, shall revert to the source cell and the old "channels". 

17. Optionally, in the case of Intra RAT/Mode PS handover, information pertaining to the radio resource 
realization of the PFCs subject to Handover can be transferred from the source BSS to the target BSS. 
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18. During the PS Handover preparation phase the new SGSN (assuming RA change) assigns a unique identifier 
(P-TMSI, Local TLLl) for data transmission in the target cell. This Local TLLl is used for data transfer 
between the target BSS and the new SGSN. This Local TLLl is not sent to the MS. After PS Handover 
Completion the MS triggers the RAU procedure. After P-TMSI reallocation, which is performed during 
Routing area update, a new Local TLLl will be derived from the P-TMSl using current MM procedures. 
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